共计 1503 个字符，预计需要花费 4 分钟才能阅读完成。
SRE 中最重要的是“E”，即 engineering(工程项目), 这是与运维工程师最大的不同。大多数运维工程师的工作繁冗且数量多，每天的工夫被大量的被动式工作所占据。而 SRE 属于主动式运维，被动发现问题，并从工程项目角度提出解决方案。
软件工程我的项目是咱们最常见的解决方案之一，通过开发各种软件工具平台，例如 CMDB,DEVOPS, 云管平台等工具，实现咱们的运维工作自动化，平台化，提供短暂继续的运维工作价值。中立性运维是个很重要的理念，咱们把开发好的工具软件交付给研发部门应用后，实践上工具软件能解决的运维工作量该当曾经同时转移给研发部门了，不须要再找咱们了，否则这个工具开发的意义就不大。中立性运维要求咱们鸟瞰整个工作流：哪些运维工作能够自动化，哪些工作须要咱们亲自执行，哪些工作能够通过开发工具软件转移给用户，只有这样能力确保咱们的工作量不会随着业务规模的扩充而线性回升
SRE 通常作为软件工程我的项目的项目经理，更多时候会专任多个角色。由运维工程师成长起来的 SRE 比纯正的开发人员更适宜治理运维我的项目，一个软件工程团队通常会有下图中的一些角色：
我的项目立项：
我的项目背景，我的项目需要，我的项目可行性调研，我的项目商业价值报告，我的项目启动大会是必不可少的，只有获得了所有相干方的共识和承诺，后续推动我的项目才会更顺利
我的项目推动：
每日站会，迭代打算板，项目管理工具 (jira, 禅道) 等都是在我的项目推动时罕用的工具和措施。每个公司的研发形式和气氛并不相同，可能推动即可。运维我的项目和业务我的项目还是有一些不同，首先是运维我的项目上线工夫
并不紧迫，其次运维我的项目的用户量和并发量并不高，但运维我的项目须要较高的可靠性。在推动我的项目时须要留神，运维我的项目不须要太过谋求前沿技术，稳固，牢靠，好用，易保护是首要准则。
我的项目落地交付：
我的项目落地交付时最难的，它并不是将我的项目上线，而后通告用户应用就算胜利。咱们要在公司外部推广工具软件，吸引更多的人应用还有大量的工作要做，例如：提供欠缺的帮忙文档和演示视频、和资深工程师及管理层沟通，让他们看到工具的价值来帮忙咱们推广、一直的收集用户吐槽，从用户角度改善软件的易用性等
注意事项：
首先时工具软件的易用性，要合乎习惯和直觉，升高用户的学习和应用老本。切勿以自我为核心开发，开发了一大堆性能，但却让用户困惑，难以上手应用，最初还是要打电话或发工单给你解决工作，这就得失相当了
其次是迭代上线，小步快跑。每次上线最有价值的小性能，晋升团队的成就感和士气，同时也能疾速的失去用户的反馈，防止谬误累积到无奈批改，还能够让 leaders 和相干方看到我的项目价值以获取后续的资源反对
再者是通用性，工具软件要尽可能多的笼罩咱们的日常运维工作量，尽量把重复性的脏活累活，或者低权限保护工作转移进来。不须要谋求所有的工作自动化，要对我的项目开发的性能做好价值评估
还有就是再推广我的项目的过程中要留神用户的反馈和情绪，咱们开发的软件可能会代替团队外部一些成员的工作，使他们的重要性降落
结语：
SRE 是通用型人才，咱们 优先拓展广度而不是深度，只有这样能力把握全局知识。
SRE 须要有运维教训，思考用户需要，探讨产品模型，组织团队，沟通合作，推动我的项目的能力，编码工作是组成部分但不是最重要的能力。SRE 不仅要解决日常的运维工作，同时要推动我的项目，应答经常呈现的变故。如果你只是想拿到需要，带上耳机，坐在工位上宁静的敲代码，无人打搅，那恐怕很难适应 SRE 的工作。SRE 须要不停的在多个工作间切换，同时要具备产品思维，因为工程项目的胜利在于最终交付的产品而不是如何编码实现。
