不遵守这条规则必定带来故障时间延长。不要在故障停机时间的压力下进行优化——要先集中精力提高承载能力。

不要过早或过度 ‘优化’到你的架构之中，为了解决问题而新加进来的一些东西往往后来都会变成运维沉重的负担。

要确保在运维工程化中开发出来的工具交接完整，如有一键启动和关停。返工或变更请求可能会破坏已经安排好的工程计划。

自动部署、自动编排、自动巡检、自动升级等自动化手段越来越多应用于云运维。

虽然自动化还存在一定风险，但云运维的自动化趋势已经不可逆转，谨慎做好统一性和灰度发布。

保持简单，别把事搞的太复杂。

• 报警异常问题，其他部分记录数据用来做趋势分析信息。
• 定期的流程查看各个地方的趋势数据。
• 不要把监控弄的很乱，不然他就没有啥意义了。
• 确保监控系统简单到让公司的每个人都能上手,你可能会很吃惊监控数据指标转换成为业务指标、市场指标和销售等等指标。

公开你的检查报告，并附上相关数据，以便他人可以容易的阅读到关键点，并能关联到响应的数据。

运维团队通常是最大的花费者。通常都会预算不足，因为没有钱的运维是很难兼顾到日益增长的公司业务规模，面对这样的挑战，运维要学会降本增益，开源节流，利用新技术实现能效比的提升。

各种各样的负载场景。从高并发处理到视频转码，从高性能并行计算到海量的网络请求。这些不同的负载场景，对网络的要求也各不相同。

持续发布的难点在于用户对于发布的理解并不彻底，包括灰度发布、测试发布、滚动发布、回滚发布等多种场景，并且每种场景都应该是可以回退的。

定时+定点+定人发布除了对生产环境的敬畏感，仪式感，更能加强跨部门联合发布的凝聚力。

铁打的营盘流水的兵，人挪活是常态，平时做好培训和分享，做为管理者，确保所有人都可以被高低替换。