本文原作者：Matthew Huxtable

小组织里，人人都是SRE Link to heading

“网站可靠性工程就是答案。”

几年前，当我通过自我说服，在一家小软件公司获得我的第一个 SRE（站点可靠性工程师）职位时，我原本以为事情会是这样。终于，有一个机制能够将我的软件工程师和系统操作员的工作具体化——当一切出问题时，我便是最后的终极异常处理者。对于任何人来说，有机会采用并实施像大型跨国公司那样用于运维的方法，本该是令人兴奋的。然而，很明显，要取得成功，就必须打破常规。

小型组织采用 SRE 方法颇具挑战。资源受限，人才引进困难，客户基础也并非牢不可破。SRE 从业者需要身兼数职，在资源有限的情况下追求更高的产出。仅具备工程、系统管理或运维的技术背景往往不够。要在 SRE 领域取得成功，需要深刻理解情感、具备影响力，并掌握组织运作的内在逻辑，才能推动变革、培育无指责的工程文化。SRE 的成功意味着要构建一种以用户满意度为先导的文化，而这只有在技术专长与人文关怀的交汇点上才能实现。

与标准教科书方法不同，在小型组织中创建专门的 SRE 资源，最佳方式是广泛分担责任。当成功以向客户交付功能来衡量时，新成立的 SRE 团队很难为自己开辟出独特的领域并赋能他人。可靠性不太可能成为一流的策略性关注点；它不能被视为理所当然，可能只有在遭遇意外故障而感到不便时才会偶尔出现。

当每一项新功能都能带来可衡量的增长，并提升服务价值时，每个人都愿意付出必要的努力来维护自己的未来生计，而这很可能就意味着要推出新的功能。

对组织风险恒温器的校准往往比较临时和粗略，更多是受情绪驱动而非量化判断。你甚至可能不需要特别关注可靠性；早期采用某项服务的人通常更能容忍相对较差的运行时间！

秉持“谁建设，谁运维”的理念，能够赋予组织内每位成员共同承担可靠性的责任，并充分发挥团队的专业技能。此外，通过共同分担生产服务的运维压力，还能增进团队成员间的相互理解与共鸣，为规模化发展奠定必要的技术基础。

同样地，实施 SRE 的从业者必须谨慎地优先考虑那些促进共享语境而非集中控制的想法。这个例子常见于试图辅助质量管理却误入歧途的做法，比如在感知到运营工作量的过度时，又把寻呼机交还回去。不幸的是，对一个大小为 1 的优先队列重新排序，并不能带来任何可察觉的变化。对于小规模的 SRE 来说，只有一个生产服务需要支持，并且个人和组织都有强烈的动机继续提供这种支持。相较于增加额外的摩擦，优先考虑共享责任和沟通更有可能在长期内取得成效。

软件系统正变得越来越复杂。凭借广泛且不断发展的社区支持，SRE（站点可靠性工程）提供了一种可持续增长此类系统的模式，该模式对各种规模的组织都具有足够的灵活性。最成功的实施案例都认识到共享责任和减少摩擦的重要性，所有这些努力都是为了实现客户成功。