应急响应是运维部门在公司最独特的一点，表现为当公司出现问题时，应该找谁或者流程应该是怎样的。我回国之后见了不少初创企业，他们网站出问题了，往往是CEO先发现，CEO打电话“哎，这个到底是怎么回事啊”，然后每一个人都说“不知道啊，不是我负责呀，我得找谁谁”。不管多大一件事都得传遍整个公司，整个效率非常混乱。
我在Google待了八年时间，这样的流程也经历过，但是最近这几年Google非常重视这一点，建立了一整套应急事件处理方式。首先要有全面监控，监控这件事情是持久不断的，重中之重。所有人都要非常了解整个监控系统在所有业务中的部署实施，其实这是我们平时花精力最多的地方。监控系统里面对整个系统所有方面都有监控，不光包括业务指标，也包括性能指标、效率指标。监控应该平台化、系统化，不停的往上积累，多做一些模板，同质化的系统就可以用同样的方法去做监控。
第二点是应急事务处理，应急事务处理分两部分，第一部分是演习，另外一部分是真正的处理流程。如何把它做好？实际上就是要不停的去演习、去做这个事情。像刚才举的例子，网站挂了，首先不应该CEO先发现，而应该是监控系统或者报警系统先告警，在发现之前就很应该明确这个东西应该谁排查，谁处理，这个信息应该早就发给合适的人去处理，甚至他应该早就在做了。如果发生特别大的，需要跨部门之间协作的问题，那不应该只是领导现场调配，而是整个组织每个人都明白这个流程应该是怎么样的，直接就做。Google甚至可以做到在一次事故中间两地交班，某个团队处理一半，然后我交接给另外一边团队，就下班回家了，持续不停的有人继续跟踪处理这件事情，而不会出现问题。这样一个模式是我觉得非常值得我们思考的。
处理完问题之后，要总结。之前听过的一个故事是，某公司业务出现了一个事故，大家加班加点，十几个小时没睡觉把这事搞定，然后领导过来就说了一句“大家辛苦了，回家睡觉吧”。但是，其实在这个时候我要说，领导光说这个其实恰恰是不够的。领导在这里应该问：为什么加班啊？这个事情为什么会发生啊，下次能不能不发生，大家能不能不加班，能不能不熬夜？这样才对, 能做到事后总结这个事情很难，但只有把这个做好了，才能降低以后问题发生的几率。
日常运维
日常运维做得最多的可能是变更管理。业务现在发展非常快，迭代速度、迭代周期非常快。其实这件事情能做好，能够做到无缝、安全、不停的变更管理，是运维部门能给公司做的最大贡献。
第二个，容量规划，当规模大到一定程度的时候，就需要有人来回答这个问题——到底要买多少新机器，能否保证明年的性能、效率，那谁来负责这件事呢？SRE部门提出这些方案，然后要确保这些指标、这些东西是有数据支撑的，确实能解决问题的。
