中小银行运维架构：解密与实战

大概一年前，我开发了一套程序，顺道写了一份运维方案，怎么写都没达到客户要求，最后一次会议沟通的时候，客户问我有没有运维的证书，我想我是开发，怎么会有运维的证书，客户接着说，“当然我不是要你去学他们的形式，而是学习他们的运维管理思想。”，我还是没明白，最后客户放弃了让我写出让他满意方案的想法。 说回这本书，这类书，不必细看，不可照搬案例，我自己的读法是提取目录，从目录架构可以看出作者的思路框架，定位到自己需要的部分，内容部分关于论题、论据、结论可以看，提取整体思路和思想，结合自己的实际情况发散，案例和方法尤其不用看，都是高度定制化的，没有参考意义。国内外的运维管理架构，基本脱胎于ITIL，后来发展出itsm、devops，一般项目itil足矣。itil一般分为事件、问题、变更、发布和配置管理，每一类管理的定义、目的、原则是什么，在这个基础上制定适合自己的方法。 一般容易忽略的是标准化流程和文档记录，标准化流程约束各方权责利，少了多少推诿扯皮撕破脸，省大事。文档记录关键在闭环，如果站在事件角度，故障处理完，生产恢复，闭环就完成了;如果站在项目角度，一季度一年的工作量分布，人工成本，问题处理背后深层原因是什么，总结分析问题提出解决方案，闭环完成，如果没有完整记录，你的分析、总结就会出现偏差;如果是产品线或市场角度，产品不好用给运维带来多少工作量，给用户带来多少故障，延迟等不好的体验，造成多大影响，运维都掌握了一手数据，反馈数据，闭环才完成。 那天坐我隔壁的销售帅哥，问我销售能给运维提供什么，我瞎说了一通，运维掌握了产品使用体验的一手信息，甚至用户最直接需求，一般来说他们不知道这些数据有什么用，也不会记录下来，这些信息或许对销售重要的。

里面有些前沿的技术方案，比如人工智能语音助手，根据自己需求可以单独查看某部分

银行运维架构书籍方面我看过的最专业的一本书

主讲小型银行的系统架构，以及运营模式，很多架构比较陈旧，不过可当做了解另一个IT行业的读本

实现智能运维任重道远，详尽devops各方面的坑

非常实用，基本上是手把手教你怎么做监控，怎么做运维，对于项目经理，项目顾问等有很好的指导作用

可能技术上没什么可讲的，细节没有。银行的技术与其它的方案区别也没有那么大，只能说是银行的实现方式吧。

作者理论基础扎实，用例详实，对运维架构断面观察之范围十分广泛，横跨监控，自动化，智能化与双活灾备等多种通用运维领域。对有亟待掌握运维建设全生态需求的人员是本不可多得的好书。唯一的缺点是此书的各个章节由多位作者分别编撰，因个人编写侧重有所不同，在阅读中稍有不连贯之感，但这并不妨碍读者随笔者进行每章内容剖析的过程。

本书主体围绕传统运维架构开展叙述，行文流畅，干货满满，美中不足的是关于新兴技术与未来发展的内容占比较少。

中规中矩，业界主流都涉及到了，不仅仅是银行，其他中小企业都是这种，能用开源尽量用好，在快速发展阶段很受用。