系统正常，只是该系统无数异常情况下的一种特例
--- 摘录自《SRE Google运维解密》
最近Google SRE很火，我们内部给每个人都配了一本《SRE Google运维解密》，希望大家能熟读，从中能取些经。
SRE的的几个核心方法论：
1）确保运维人员长期关注研发工作；
2）在保障服务SLO的前提下最大化迭代速度；
3）重视监控系统；
4）应急事件处理，重视运维手册维护以及on-call机制；
5）变更管理自动化；
6）合理对需求进行预测和对容量进行相应规划。
看完第一章 SRE方法论后就知道google SRE并不是那么容易学习了。
SRE是另一个很火的概念devops在google的最佳实践，结合google的特点进行了扩展。在SRE的几个核心方法论中第一条最重要，是做好其他几个方法论的前提和驱动力。一般运维(ops)和开发部门(dev)是独立的两个部门，这两个部门有截然不同的目标述求，ops希望稳定压倒一切，系统上线后一百年不变才好；dev部门希望尽快完成业务部门提出的需求，巴不得随时随地变更上线。这个矛盾导致两个部门“不对付”，是IT内部不和谐声音的来源，处理不当会产生严重的办公室政治，对工作和团队建设都严重不利。（这种情况可以参考运维界难得的一本小说《凤凰项目-一个IT运维的传奇故事》中关于运维部门和开发部门斗智斗勇、互黑的故事，和现实中碰到的真是一样一样的，说明ops和dev的矛盾和国别无关，人种无关）。
Devops希望的是dev和ops尽量的融合，一般是两个部门尽量的融合，譬如，归属一个团队、由同一人领导、集中办公等等。google直接一步到位---dev和ops是一个人（合体了），并且SRE 至少50%精力用于花在真实的开发工作上。招聘时以开发人员的要求来招聘SRE，SRE的招聘要求原则上比普通业务开发人员还要高，既懂开发又要懂运维。这样的好处是显而易见的，一个人身上哪个地方疼只有自己最清楚，运维过程中的痛点开发人员是不知道的，运维人员提出来开发人员也不一定能切身体会，做一个完全好用的运维功能出来。
现在的开发更多的是业务开发，简单点说是用一堆if/else逻辑驱动数据将业务逻辑实现出来，很多业务开发人员对系统的健壮性、可维护性根本不了解，也没能力了解，开发过程中也不会考虑到（业务功能都做不完，哪还有空去考虑健壮性啊~）。这就需要运维开发人员补充进来，从系统的冗余、应急、告警、监控等多维度去给业务系统打补丁，提高系统的稳定性。这部分工作现在很多场合下是欠缺的，因为不能直接产生价值也导致管理层重视不够。
当运维人员有开发能力（如同一个木匠有了趁手的斧头锯子），并且能有一半以上的精力投入到运维功能的开发中，把业务系统再穿上一件运维功能（健壮性、可用性、可维护性方面）的铠甲，那么不仅仅会提升系统的可用性，而且能够更好的配合业务开发人员实行持续集成(CI)，持续部署（CD）这些高阶玩法，否则系统本身已是弱不禁风，怎么经得起花样翻新的折腾！
所以，想学习SRE，首先看看能否做到SRE核心方法论中的第一条，如果运维人员还是一些仅仅只会看看告警、查查SQL，那么很难学到SRE精髓。当然即使做不到，其他方面也可以参照学习，这本书上还是有很多其他值得借鉴的部分，譬如方法论的第二点，制定好SLO，根据SLO决定上线频度（有理有据和开发争取不给上线:)）；方法论第四点建立告警监控的轮值制度等等。
