e-works数字化企业网  »  文章频道  »  基础信息化  »  运维管理

运维逼格提升心法:从报警到预警,如何有效提升SLO

2017/10/4    来源:51CTO    作者:王雪燕      
关键字:运维  SLO  
本文分享主线以时间为序:从建立、实现 SLO,到预警的提出和成熟、预警系统的布设,再到运维准入门槛的提出、故障的自动恢复。
    当下,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 次数过多,就需要特殊监控。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐