-
提升速度
-
持续提高可靠性
-
保持精简
-
快速开发
-
免回归的版本周期
-
通过自动化解决复杂问题
-
跨部门共享生产知识
-
在工程部门之间设置共享的目标和对象。
-
领导者接纳并执行。
-
为各种服务设定“服务水平目标”（SLO）文化。在可靠性和稳定性（it成本）方面，我们要走多远？
-
明确定义产品/服务所有权，包括将SLO作为生产准备要求的一部分。
-
要从利弊两方面分析我们为什么要做这件事？（要提到商务司机。）
-
对每个团队/成员的期望是什么？新的结构在未来会是什么样的？
-
领导如何帮助避免扩大知识差距或减轻未来的挑战/风险？
-
带有时间表路线图的高层次里程碑——我们如何到达那里？
-
文化：寻求帮助、合作、教导和负责任
-
雇佣合适的人才（面向未来的以及经验丰富的人才）。
-
组织团队以利于平滑传播知识。
-
雇佣员工是为了解决复杂问题，而不是为了扩大规模（通过自动化来扩大规模）。
-
团队应该对解决复杂的问题感到兴奋。
-
50%的SRE时间应用于质量工程工作。
-
使用星型方法来实现任何更改。在没有明确目标和预期结果的情况下，不要引入任何改变（无论多么小）。
-
实现成功：倾听用户（工程师），适应并推动采用的想法。
-
模板
-
带有关键性能指标的仪表板（保持简单，愚蠢）。
-
最佳实践的剧本
-
用于监视和安全的通用插件/模板。
-
自动化工具/剧本是版本控制的，并遵循自助模式。
-
原则：
-
自助服务
-
高速
-
一致性
-
加强ACL和策略
-
质量和安全应该移到SDLC的左边，并且应该是版本工程自动化的一部分。
-
每个版本都应该通过KPI的镜头进行验证，并与设定的SLO进行比较。
-
负载和容量在放行前要进行测试和认证。
-
构建一个测试环境来检测零MTTR，从而避免生产错误。
-
产品准备就绪后才发布服务。
-
在客户端和服务端使用工具收集时间序列数据。
-
使开发人员能够轻松地向监控系统添加各种指标。
-
为每个常用指标构建一组可重用的SLI模板；这也使得每个人更容易理解特定SLI的含义。
-
每次都修正（战术和战略）。
-
不要责怪任何人，专注于解决方案、过程和技术。
-
通过适当的发布周期，有一个过程来跟踪问题和采取的修复行动。
-
定期召开架构和产品评审会议。
