践行 On-Call 文化的4点经验总结（践行以人民为中心的发展思想）

践行 On-Call 文化的4点经验总结（践行以人民为中心的发展思想）

On-Call 文化在欧美的技术圈已经成为共识，而在国内，这一文化体系多是大型科技公司的专属。而随着云计算在各行各业的不断渗透，On-Call 文化就如同“创新”一样，逐渐成为每一个科技公司的标配。其价值与意义可参考睿象云先前发表的文章《事件管理平台应用价值浅析》。作为国内领先的智能告警管理平台，睿象云有自身的 On-Call 文化。从 2018年公司成立开始，睿象云就始终致力于推动与践行 On-Call 文化。如今在公司内部，On-Call 文化已渗透到各个团队，很少量的运维同事即可管理支撑全公司业务的服务器，运维效率达到科技公司平均值的3倍。 基于此，睿象云召集内部高级工程师进行讨论，总结出4 个中肯的建议，分享给各位用户大大，希望大家在用好智能告警管理平台的道路上更进一步！ 以下便是讨论总结出的运维建议，尤其适用于正在推广 On-Call 文化的科技企业： 1、On-Call 事件处理应该是整个公司的事情；2、设计架构时，务必跨分区灾备；3、处理问题要有流水记录，便于复盘优化；4、不要整天盯着图表； 接下来我们将详细介绍每一个建议。

1 On-Call 事件处理应该是整个公司的事情传统科技公司往往设有专门的运维团队，负责机房的运营和维护。公司服务器出现任何故障都先由运维团队解决，涉及存储，网络，CPU负载甚至到应用优化。这就意味着需要庞大的运维团队支持整个公司的机房/服务器正常运转，并且公司业务规模越大，运维团队也就越庞大。 对于大部分科技公司来说，服务器正常运转仅仅是业务成功最基础的要素，如此庞大的运维团队加剧了公司组织管理和成本管控的压力。并且，运维团队的职能单一，而机房/服务器故障的原因却五花八门，在非机器本身故障出现时（比如应用系统优化等），庞大的运维团队也无从下手。 “who build it，who run it”（“谁构建，谁运维”）出自 Amazon Web Service 前 CEO Andy Jessie（现任Amazon CEO）。这是为企业践行 DevOps 文化提出的箴言。在 On-Call 领域，这一准则同样适用。 我们认为 On-Call 事件处理应该泛化到整个公司，包括运维工程师，研发工程师，测试工程师，产品经理，以及 CTO 甚至 CEO。 On-Call 事件触发时，应先根据特定属性分类，基础运维类问题如 ：网络故障、硬件故障、IO 异常、告警积压等由运维团队负责，应用类问题如：消息队列堵塞消费缓慢，数据库数据查询更新缓慢等问题由研发团队负责，而直接涉及客户体验的问题，如界面加载报错、页面未找到、样式混乱、加载速度慢等问题应先由产品团队确认问题再分发到对应团队。最后是第一次出现的偶发性事件，可先汇总到运维，确定根源后再协调对应团队同事处理。 将 On-Call 泛化后，运维团队的边际效应将会递减。意味着在业务规模不断扩张期间，公司无形中降低了组织管理和成本管控压力，同时，可将更多资源投入到核心业务上。2 设计架构时，务必跨分区灾备设计业务架构时设置灾备服务器是很多科技企业的标配，但跨分区灾备却并不是所有科技企业的共识。但这一点很重要，一定要做到谨行俭用。传统机房灾备为节省资源，会设计为一地灾备的模式。从物理空间上来说，这样的灾备模式流于表面--当遇到恶劣天气，突发电气故障或者人为损坏时，同一个分区的服务器将会受到影响。而跨分区服务器同时不可用的概率则很低。因此，为保证服务的高可用性，设计架构时应考虑跨分区灾备。3 处理问题要有流水记录，便于复盘优化运维人员会在任何意想不到的时刻遇到机器故障，未处理的故障和已处理完的故障都会反映出机器的健康状况。对于此，运维人员应该有一本“事件流水账目表”，将每天遇到的问题记录下来，以此为基础，分析定位根本原因并对系统进行优化。同时，还应该根据根因定位对相关同事（如研发）提出要求，以规范系统模块，避免/根除类似事件再次发生。4 不要整天盯着图表信任系统很重要。值班并不意味着运维人员需要整天盯着图表，这只会耗费很多不必要的时间精力。运维人员在设置好阈值，并将紧急级别高的事件设定好相应通知（比如电话或短信即时、主动通知）的情况下；每天巡检一次即可。在值班空闲时间，运维人员应该集中精力解决持续出现的长期问题如：资源的结构性优化、深入到模块API级别的应用监控的精细化管理、关键设备巡检和装配的自动化流程改进，在迭代上升的管理规范中稳步提升系统的自动化效能，最终可为产品、研发、测试团队提供有力的数据依据和优化的持续性数据支持，真正的形成运维、研发、设计的三维一体化体系。