集中运维与分散运维的比较 - thenewstack

集中操作与分散操作的概念早于站点可靠性工程(SRE) 和DevOps。
与大多数与运营和工程相关的事情一样，一般来说，很大程度上取决于业务的规模和成熟度，以及正在运行的基础设施（本地、公共云、混合等）。此外，访问共享工具对于集中式和分散式运维团队的成功至关重要。
在集中式模型中，通常可以减轻由于拥有全部或部分堆栈以及直接访问安全团队而引起的安全问题，这些团队审查工作并确保编写代码时考虑了安全最佳实践。但代价是支持应用程序的发布和响应影响客户和公司声誉的随叫随到问题需要更长的时间。
在比较集中式和分散式运维的人为因素时，应该考虑支持每种情况的软件架构：
例如，对于基于微服务的架构，拥有特定服务运营的各个团队可能具有优势——尤其是如果他们开发了服务——因为他们最了解其细微差别和内部动态。一般来说，在这种类型的示例中对服务进行编码的团队可能会更快地调试由于软件错误引起的操作问题，而在调试由于环境问题（包括底层依赖项或基础设施）引起的问题时可能会更慢。
从人数的角度来看，随叫随到的团队应该同时拥有开发人员和运营商。但是，随着服务的成熟，将运维转移到中央 SRE 团队以降低成本和倦怠可能是有意义的，并让工程师有时间重新编码和开发新功能，这通常是他们的首选活动。
围绕 SRE 或 DevOps 的文化也很重要。尤其是随叫随到的操作人员是一项 24/7 全天候的工作，具有全天候的压力、压力和期望。不是每个人都适合它。但它通常至少是运营商工作的一部分，尤其适合在较小、较新或分散的组织中。
在许多情况下，随叫随到是痛苦的，人们在巨大的压力和永久的压力下工作。他们也可能正在处理过时的 wiki 或缺乏有关故障排除或解决随叫随到问题所需发生的事情的信息。甚至可能不清楚谁对完全处理事情所需的某些行动负责。即使在最好的情况下，也有很多活动部分，公司依靠人来采取行动。

• 在集中式模型中：当一个团队拥有运维的所有责任和问责制时，团队之间和运维管理员之间几乎不会发生相互指责。这种结构对于运营的集中式方法更为重要，但内部团队成员与与外部服务提供商打交道的运营商之间仍然存在裂缝。响应问题也需要更长的时间，因为有既定且严格的流程。

• 在分散模式中：当部门之间的职责分工并且不清楚谁对运营要素负责和/或负责时，混乱很快就会发生，尤其是在随叫随到的情况下。采用这种方法通常需要具有不同经验水平的操作员在工作中随叫随到学习并通过失败收集知识。该模型还允许组织将可靠性文化传播到整个软件开发团队，使其至少成为每个人工作的一部分。