【51CTO.com原创稿件】当下，IT 运维成为企业的核心竞争力，从过去人肉保障的阶段，一直到现在引入 AI 和各种计算的方式来实现稳定性。在进阶的过程中，如何评价运维的质量，是摆在运维人员和服务对象/业务方之间的难题。
在由 51CTO 主办的第十四期“Tech Neo”技术沙龙活动中，搜狗 SRE 负责人黄昕老师以此难题为开端，逐步深入展开，讲解具体实现细节。分享主线以时间为序：从建立、实现 SLO，到预警的提出和成熟、预警系统的布设，再到运维准入门槛的提出、故障的自动恢复。
如何建立 SLO
SLO 即服务水平目标，通过建立运维 SLO，如稳定性目标、服务时长等，实现用数据的方式合理评价运维工作效率。
十年前，没有各种监控系统，要以纯人肉的方式，来实现稳定性，整个运维行业是人跟着报警走的状态。
这样的方式非常累且毫无成就感，大家对运维的概念除了悲观，别无其他。所以建立一个能够衡量运维工作，通过数据就可了解到质量的指标成为运维工程师们迫切要做的事情。
在做这件事情之前，其中非常重要的环节就是取得业务线的信任。大多运维人员对业务架构、线上服务状态都非常了解，但对每个模块、程序内部逻辑了解的不是那么详尽。进而对程序在什么状态下会出故障，以及出现故障的原因也不是很清晰。
这时，要针对业务线深度合作，在取得信任的前提下，熟知每个模块的具体实现逻辑、每个请求包的大小、请求的正常状态、返回标准等等。
因为没有百分百稳定的系统，所以需要了解业务需求，明确稳定性需求。就电商服务来说，能接受页面展示微慢，但绝对不能丢失交易信息，不能算错钱。
对搜索服务来说，能允许结果有些偏差，但不允许页面不能访问。也就是说，要对需求进行逐一分类、分级，不能眉毛胡子一把抓，每个模块都保证百分百稳定，这是不现实的。
在 SLO 建立过程中，一定要注意避免不可抗力，因为指标一旦建立，就是公司整个业务，对整个运维部门的评价体系。故在制定指标时，要可维护，可衡量，可提高。
如受到黑客攻击，不设为故障。把恢复时长、范围控制等构成运维 SLO，也就是承诺的服务质量。
在建立各种指标后，紧接着是根据需求来选择监控系统（监控部分后文有展开说明），搜狗最早采用第三方系统，之后逐步转为自研。
最后是 SLO 的具体实施过程，我们秉承一个观点是：数据先行，不要在意一城一池的得失。也就是发现一个问题，首先展示现实状态，哪怕数据下跌了 50%。
在此这基础上，通过运维人员的介入，实现数据不断提升，才能取得优先的信任。这是一个互相交互，正反馈的方式。
如何避免不可抗力呢？首先，我们永远无法知道硬件什么时候出现故障，所以，要对架构进行相应优化，将硬件的故障全部容错掉。
最简单的办法就是关键节点必须冗余，避免群死群伤。切记从用户视角来定义 SLO，就算服务器宕机，但是用户感受不到，那么，对于服务就是稳定的。
还有就是代码上线，经过一系列检查没问题，运行一段时间以后，可能是因为内存泄露，也可能是因为线下测试无法覆盖线上所有的情况，突然崩溃。
这时可以采用服务降级&快速扩容的方式来应对；也可以利用缓存，在很大程度上解决代码故障导致的问题，让用户无感或近似无感，给用户展示一个 5 分钟前的结果要好过用户什么都看不到。
如何实现 SLO
搜狗实现 SLO 首先是运维人员一定避免自己操作失误，同时需要 7×24 及时响应报警。其次是模块的原子化与标准化，谨记要抛弃运维手册，简化故障恢复手段。
常规运维状态是各管一部分，最多是二人互备。在这样情况下，当运维人员离职，就出现断档情况。把所有的模块原子化，就是为应对在这个时期也可做到故障顺利恢复。
模块的原子化就是每个模块把自有代码、配置、数据、上线统一做成一个黑盒，对外是一个个接口。
模块内部随意调整，相互之间沟通协调不容易出现问题。模块的操作标准化是要制定一个标准流程。还有就是一定要备份，尤其是环境变量的备份。
基于模块的原子化和操作标准化之后，要抛弃运维手册，把运维手册简化成几条原则。
这个阶段，通过手快的方式，提高故障响应速度，运维得到好评，故障降低，线上稳定性提升，运维靠谱并赢得业务的信任。
这背后的苦，只能运维自己扛，但不能一直这样持续下去。所以我开始反思运维到底是做什么的？如何能不出现故障？
- 从简单的为了不背锅而干活，转变为线上服务的管理者/服务者，管理线上整个环境和线上所有的流程，提升主观能动性。
- 虽然职责上不对线上程序的策略负责，但要比开发更明白模块和模块之间的关系。
- 需要冗余资源，来保证某些服务能达到更高的稳定性。
- 虽然冗余资源，但还是会出现难以避免的故障，如模块所在机器网卡流量、IO、内存突涨等等，需要有快速扩容的能力。
- 铁打的公司，流水的开发，经常会有一些重复性的故障，做运维的要在项目制定的时候就开始介入，建立和不断完善运维准入门槛这个制度，帮开发把好关。
如何提高 SLO
经过实现 SLO 的过程，我总结了很多经验教训。很多故障在发生之前，都会产生一些表象。基于这些因素，在了解代码策略的基础上，要分析所有可能出问题的点。
预警的提出和成熟
预警策略需要做的三件事分别是：
- 系统资源层面。如 IO 性能，CPU、内存等。
- 模块存活情况。这里指通用规则，保证服务面向整体顺畅，允许 1 到 2 个节点出现问题。
- 各模块的特殊监控需求。如常见的 AB 请求，请求或出现 504 次数过多，就需要特殊监控。
对于系统资源层面，运维可以通过 TOP 或 PSO 来进行，但对于模块存活情况和各模块的特殊监控需求就需要开发从接口和 log 上给予支持。
预警系统的实现
预警系统自始，我们就采用自主研发的方式，第一阶段就是信息的产生和收集，框架如下图：
在各个服务节点上布设脚本进行收集，对于系统的资源层面，简单计算这个模块当前系统使用情况，对于各模块特殊的监控需求，提供可扩展功能。
一类是开发将自己的监控需求，写入 log，运维去计算单位时间 log 出现的次数。
另一类，是模块提供接口，运维访问接口，进而拿到当前模块多少线程，线程数的处理情况等信息。
针对单机收集之后，然后发给消息列队，只要完成在没报警之前通知运维人员就好，所以对性能的要求不是很高，消息队列的时效性在 1 分钟，甚至是几分钟都可接受。
消息列队还对数据进行清洗和合并，将同一产品，同一模块的数据进行合并之后，洗成一个服务这一分钟的状态。
预警系统还布设一个规则库，对于规则库的管理，其实就是一个用户的 UI，自己写规则，将规则存到库中，并将规则库做成词典，供给程序加载。
在汇总规则过滤环节，规则作为加载的数据文件，从消息队列中取出所有数据进行过滤，过滤之后，决定要不要报警。达到在故障前报警，人工介入处理，对用户无感。
如下图，是某模块规则展示与规则进行的绘图情况：
左上是某模块规则展示，每条规则都包含规则名和规则明细。右下是规则进行的绘图情况，采集过来的每个指标都有一个趋势。
当这些规则产生之后，整个服务应用在每次挂之前，都会有一个预挂状态，预挂时报警就会产出，运维人员收到报警，就会对故障有一定的心理准备，针对问题定向处理，速度也会快很多。
在很多情况下，都能在服务还没有整体出问题暴露给用户之前，就实现很好的人工介入，保证不产生报警和用户体验的下降。
运维准入门槛
经过建设、实现、提高 SLO 整个过程之后，又提出运维准入门槛。
这里主要分享三方面：
- 所有模块必须有预警逻辑。开发交付给运维的所有模块，必须有综上所有机制，否则无法保证此模块的稳定性。
- 所有可能产生的故障点必须有相应 log，即可被监控到。不能出现开发私自写逻辑，不告知运维，等线程出现故障查不出的情况。
- 带病坚持工作的模块，运维不负责 SLO。因为互联网公司日新月异，要保障业务的快速发展，允许快速迭代，但不承诺服务质量或降低服务质量标准。
故障自动恢复
做了 SLO，定下了运维准入门槛，可以提前预警，但只是稳定性不受影响，还是要去处理故障。目前，搜狗正在做的事情是故障自动恢复。
基于过往经验来看，重启可以解决 90% 的问题，回滚可以再解决 90% 的问题，真正重启和回滚都解决不了的问题，出现的几率很小。
如果重启和回滚无法解决，那就是系统扛不住，就需要快速扩容的能力，获得足够的资源。再就是在故障恢复时，可对服务降级。
目前实施的手段，将请求给予全系统唯一的 id，通过对逐层模块的 log 进行定位和分析，定位到具体出问题的点，并和预警/报警同步以页面的形式提供给运维人员。
正在尝试将部分确定故障的处理方式固化，在故障定位页面提供一键操作的逻辑，实现部分故障的快速恢复。
未来的展望
对未来，主要有两方面展望，分别是：将人工智能引入到规则库的管理和故障的根因分析。
- 对于规则库的管理。这是一件很头痛的事情，引入人工智能的方式，可根据历史情况去对阈值进行随时调试，而不是纯依赖于运维人员的经验。
- 故障的根因分析。一方面查询整个系统的各个层级出现的情况，根据实际展示的情况去进行原因的分析。另一方面，由查询引起模块在其他资源层面的变化反推某个模块产生的故障及原因。
2008 年加入搜狗，目前带领团队负责搜狗搜索的所有运维事务，主导了搜狗搜索的多次重大升级，在运维标准化和自动化方面进行了多方面的实践并取得良好的结果，在 SLO 实现方面具有丰富经验。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
