运维的目标是减少手动性,重复性的,可以被自动化的目标是构建出无须人工干预、可以自主运行的监控系统。
通过事先预案,实际处理,并且将规范步骤记录在事故应对手册上,经过应对处理后的规范化步骤,才是降低错误发生的事故率的良方。
而不是单靠高级工程师插手处理,虽然不论多么完备的手册也无法替代人对意外的处理,但是在巨大的时间压力和产品压力下,
运维手册中记录的清晰调试步骤和分析方法对处理问题是不可或缺的。
大部分的生产事故由新版本变更部署而导致的,建议使用自动化来完成部署, 采用渐进式发布机制可迅速而准确地检测到问题的发生,当出现问题时,安全迅速地回退改动。
一个业务的容量规划,不仅仅要包括自然增长(随着用户使用量上升,资源用量也上升),也需要包括一些非自然增长的因素(新功能的发布、商业推广,以及其他商业因素在内)。
了解开发环境的配置和项目发布流程可以确保他们和开发团队联系密切。
针对现有的服务监控盲点增加新的监控,了解监控逻辑,同时将这些异常情况与系统知识相结合。
事后总结是持续改进的一个重要部分。但是,这些事后总结如果被束之高阁是没有什么用的。
每个团队必须收集,并且整理有价值的事后总结文档,将它们用于未来新手的教育材料。
某些事后总结文档就是需要死记硬背的,某些事后总结文档可以作为课程进行教授,一起讨论背后的处理逻辑和过程。
这种活动可以帮助新人快速融入。
运维部门要多和产品研发部门、测试部门、最终用户进行交流体验,提取分析。
不同团队的沟通和协作非常重要,一般部门会开例会。这类例会需要提前浓缩,提交现有需要协作解决的问题。
在这个会议中,简短清晰的描述问题的状况,起因,推进方案等。
这样,那些关心服务的人对服务状态的了解程度得到了提高,同时也能提高服务自身的运维质量。
一般来说,这样的会议是针对整个服务的构建的,而不是找事故责任人。
这个会议的目标是,在会议结束后,每个参会者对服务的状态了解程度达到一致。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。