最近都在沉淀。手头没有事情时，就读读技术类书籍，如果时间再充裕，学习一项技能，获得资质认证。这段时间年底有些琐事，2022准备all in Machine Learning，来研究应对数据中心智能化的一些挑战。
工作快10年了。现在才发现，同样是做一件事情，平台不同，结果也不一样，效益更不一样。这个平台可以是不同公司、不同部门、不同团队。在这几年的运维中，笔者感触尤为明显。在组织中，有大把人以平台的成绩沾沾自喜，笔者觉得那是错把平台当本事，看不清自己，自信过头了。最近在断断续续阅读google SRE的书籍，这是一本看的最有启发的一本书，在阅读时会不自觉的联系工作实际情况来对比，引发共鸣。
在运维生命周期中，分为7个方面，产品设计、软件开发、容量规划、测试与发布、事后总结/问题分析、应急事件处理、监控，这个七个方面从上到下组成服务可靠度层级模型。金字塔模型从最低级的能够正常对外服务，到被动救火和应急，再到最高级的主动控制服务状态，阐述了服务可靠性的基本和高级需求。
服务可靠度层级模型-运维金字塔
1、监控。
监控系统帮助我们识别服务是不是在正常工作，可以在用户发现问题前发现系统中存在的问题。监控工作在运维生命周期中处于最低链中，占用时间多，但价值含量低。
2、应急事件处理
发现系统中存在的问题，不一定是要把问题一次性修复好，而是利用备用手段、关闭非必要功能等系统降级方法等方法来应对应急事件，保障业务正常后，才开始一步步解决故障问题。在应急事件中，由于压力大急于解决问题，会绕开必要的流程，在这个过程中往往会出现人为错误。应急事件的处理可以通过有效应急手册和周期的应急演练来保障和强化。
3、事后总结和问题分析
任何一个事故发生后，团队应该写一份“对事不对人”事后总结，系统性、逻辑性的讨论事故过程。从每个错误中学习，建立更好的预防措施，将系统变得更加可靠。在运维中，我们不能“修好”某个人，但是可以通过改善系统和流程从而更好的协助他在设计和维护系统时，做出更多的正确选择。
4、测试与发布
测试是提高可靠性投入回报比最高的一种手段。完善的测试可以提供足够的细节信息，帮助我们有效的预测系统未来的可靠度。通过增加测试，可以保证发布岛到生产系统中不会出现某些类型的问题。测试包括单元测试、集成测试、系统测试。
5、容量规划
收集对项目需求的预测，制订资源采购、构建和分配计划。
6、软件开发
在运维生命周期中，开发服务于软件的软件，支撑业务系统的可靠运行。有足够的技术能力，设计和构建自动化工具来取代人工手动操作，改进所维护的服务，使其变得更稳定和更易于维护。
7、产品设计
审核产品和服务，确保符合可靠性标准和最佳实践，提供具体的建议来提高可靠性，是服务或者系统发布的第一道守门人。此阶段是金字塔的最高阶段，反作用于系统的构建和运行，使得系统具有可靠性、天然的可维护性。
这个模型可以回答你的一个问题，也是一线运维人员也经常疑惑的问题：为什么我工作时间最长，工资还是最低呢？有了这个模型，在运维中就应该往上走，多参与一些高级需求，才能做的更好。
网友评论