微盟故障带来的四点运维思考
极客时间编辑部
讲述：初明明大小：3.48M时长：03:48
来源： OSCHINA 社区
你好，欢迎收听极客视点。
2 月 23 日，微盟出现了大规模系统故障，据悉，故障原因是微盟运维部门核心员工在生产环境中进行“删库”操作。此前，极客时间《软件测试 52 讲》专栏作者茹炳晟的一篇文章从运维角度出发，就微盟故障事件提出了四点思考。以下是重点内容。
思考一：一个普通个体，能在多大程度上破坏系统？
在信息时代，一个普通人完全可以摧毁一个系统。很多互联网产品运维人员的权限比较大，在 B 轮或者 C 轮的企业中尤为普遍。先不谈运维人员是否会出于恶意，故意破坏自己的系统，但是忙中出错的概率还是不小的。
这个问题带给我们的启示是，要充分重视个人在系统中可能产生的作用，必须对个人的行为进行严格监管，避免由个人引发的系统性故障。这也是为什么大型企业都会建立比较完善的分级和分层发布流程的原因，通过层层监管和审批，避免个人单点故障的无限放大。当然，这些监管和审批必须要纳入到由技术驱动的 DevOps 流水线中来完成，而不是靠传统的领导签字。
思考二：“人肉运维”还有多大的生存空间？
首先解释下“人肉运维”，那些在生产环境中，直接敲命令来完成的各种运维操作，都属于人肉运维的范畴。左耳朵耗子曾说过：“一个公司的运维能力的强弱，和你在生产环境敲命令的多少成正比”。运维能力越弱，在生产环境上直接执行各种命令的频次就越高；运维能力越强，人直接和生产环境打交道的机会就越少。
我们应该尽可能避免任何形式的人肉运维，行为准则应是“人管代码，代码管机器”，而不是“人直接管机器”。
思考三：运维已经积累了大量实践，为什么依旧举步维艰？
主要有两个原因：一是现在软件架构的发展速度在某种程度上超越了运维自身的发展。虽然运维的技术体系一直在进步，各种 CI/CD 的工具链、容器技术、自动化部署工具、系统监控方案都在日趋成熟，运维人员的能力也在不断增强。但是，运维的对象也变得越来越复杂，无论是依赖关系，还是集群规模，都比以往任何时候要复杂。可以说，“水涨船高”是现代运维所面临的主要矛盾。
另一个原因是，很多运维的最佳实践在实际工作中被“教条化”了。在实际执行过程中，往往是形式主义占了上风，所以这些机制并没有发挥出应该有的效果。正确的做法是，把这类方法完整嵌入到流水线的执行步骤中去，而不是靠人为的方式来实施。
思考四：运维部门是成本中心吗？
很多人把运维部门归在成本中心，简单来讲就是花钱的部门。运维是成本中心的宿命论对于运维的发展其实是很不利的。如果运维部门长期处于机械性地发布执行和生产环境救火的状态，那么就会陷入无止境的恶性循环。
很多时候，我们总是解决了看得见的问题，但是看不见的问题往往会在看不见的地方聚集，这类问题一旦出现就都是大问题。所以，我们需要转变运维是成本中心的思维定式，让运维的同学能够更积极地思考和解决系统性的问题。
以上就是茹炳晟对于微盟事件的进一步思考，希望对你有所启发。
原文链接：运维进化论：微盟故障给我们的启示
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
Monday人管代码，代码管机器。总结到位2
收起评论