SRE体系08----软件项目实践

SRE中最重要的是“E”，即engineering(工程项目),这是与运维工程师最大的不同。大多数运维工程师的工作繁杂且数量多，每天的时间被大量的被动式工作所占据。而SRE属于主动式运维，主动发现问题，并从工程项目角度提出解决方案。

软件工程项目是我们最常见的解决方案之一，通过开发各种软件工具平台，例如CMDB,DEVOPS,云管平台等工具，实现我们的运维工作自动化，平台化，提供长久持续的运维工作价值。中立性运维是个很重要的理念，我们把开发好的工具软件交付给研发部门使用后，理论上工具软件能解决的运维工作量应当已经同时转移给研发部门了，不需要再找我们了，否则这个工具开发的意义就不大。中立性运维要求我们鸟瞰整个工作流：哪些运维工作可以自动化，哪些工作需要我们亲自执行，哪些工作可以通过开发工具软件转移给用户，只有这样才能确保我们的工作量不会随着业务规模的扩大而线性上升

SRE通常作为软件工程项目的项目经理，更多时候会兼任多个角色。由运维工程师成长起来的SRE比纯粹的开发人员更适合管理运维项目，一个软件工程团队通常会有下图中的一些角色：

项目立项：

项目背景，项目需求，项目可行性调研，项目商业价值报告，项目启动大会是必不可少的，只有取得了所有相关方的共识和承诺，后续推进项目才会更顺利

项目推进：

每日站会，迭代计划板，项目管理工具(jira,禅道)等都是在项目推进时常用的工具和措施。每个公司的研发方式和氛围并不相同，能够推进即可。 运维项目和业务项目还是有一些不同，首先是运维项目上线时间
并不紧迫，其次运维项目的用户量和并发量并不高，但运维项目需要较高的可靠性。在推进项目时需要注意，运维项目不需要太过追求前沿技术，稳定，可靠，好用，易维护是首要原则。

项目落地交付：

项目落地交付时最难的，它并不是将项目上线，然后通告用户使用就算成功。我们要在公司内部推广工具软件，吸引更多的人使用还有大量的工作要做，例如：提供完善的帮助文档和演示视频、和资深工程师及管理层沟通，让他们看到工具的价值来帮助我们推广、不断的收集用户吐槽，从用户角度改善软件的易用性等

注意事项：

首先时工具软件的易用性，要符合习惯和直觉，降低用户的学习和使用成本。切勿以自我为中心开发，开发了一大堆功能，但却让用户困惑，难以上手使用，最后还是要打电话或发工单给你处理工作，这就得不偿失了

其次是迭代上线，小步快跑。 每次上线最有价值的小功能，提升团队的成就感和士气，同时也能快速的得到用户的反馈，避免错误累积到无法修改，还可以让leaders和相关方看到项目价值以获取后续的资源支持

再者是通用性，工具软件要尽可能多的覆盖我们的日常运维工作量，尽量把重复性的脏活累活，或者低权限维护工作转移出去。不需要追求所有的工作自动化，要对项目开发的功能做好价值评估

还有就是再推广项目的过程中要注意用户的反应和情绪，我们开发的软件可能会代替团队内部一些成员的工作，使他们的重要性下降

结语：

SRE是通用型人才，我们优先拓展广度而不是深度，只有这样才能掌握全局知识。

SRE需要有运维经验，思考用户需求，讨论产品模型，组织团队，沟通协作，推进项目的能力，编码工作是组成部分但不是最重要的能力。SRE不仅要处理日常的运维工作，同时要推进项目，应对常常出现的变故。如果你只是想拿到需求，带上耳机，坐在工位上安静的敲代码，无人打扰，那恐怕很难适应SRE的工作。SRE需要不停的在多个任务间切换，同时要具备产品思维，因为工程项目的成功在于最终交付的产品而不是如何编码实现。