为满足客户增长而不断地向运营团队中增加工程师是不可行的。谷歌的网站可靠性工程（SRE）原则可以提供帮助，为运营问题带来软件工程解决方案。在这篇文章中，我们将看看我们如何改变我们的全球网络运营团队，放弃传统的网络工程正统观念，取而代之的是SRE。继续阅读，了解谷歌的生产网络团队是如何解决这个问题的，淘客助手，并考虑如何将SRE原则融入到自己的组织中。

扩展到极限

在一个100人的团队中，沟通很困难，决策更困难。结果，一种抵制变革的倾向悄然出现。随着对变革的抵制，淘客公众号系统，谷歌的敏捷开发团队很难得到支持。因此，作为合乎逻辑的下一步，我们将这个庞大的团队分成更小的团队，每个团队都更加专注。这当然是必要的，它帮助我们更深入地研究技术，做出更好的决定，但这也有时间限制。这项技术每周都在发展，最终工作量开始超过可用的工程资源。对专业技术的不断需求意味着不可能简单地让更多的人来解决这个问题。

举个例子，假设谷歌的网络有100个路由器承载其生产流量，我们希望每个季度升级每个路由器。好吧，这大概是33个路由器，每个工程现场33个人，或者每人一个。这是小菜一碟：我们每个季度都要升级一台路由器。

这听起来并不累赘，但假设我们在最新版本中发现了一个bug，我们需要回滚。此外，当我们有1000个路由器时会发生什么？现在每个工程师每月要升级10台路由器。一万台路由器怎么样？你开玩笑吧。全年每天都在升级路由器软件？很明显，我们最终会把这项工作排除在其他重要工作之外，努力雇佣足够的人（并培训他们！）为了跟上需求。

寻找新的希望

检查，检查，检查你可能会想，"升级路由器与改造团队有什么关系？"运营谷歌网络的领域专业知识来之不易；我们希望将我们的网络工程师转变为SRE（而不仅仅是用SRE替换工程师），这样我们就可以留住他们以及他们在软件和系统方面的专业知识。我们谨慎地对待这一点，并通过一系列的工程胜利来增强我们的信心，这次路由器升级挑战是我们的第一次。

升级路由器是软件工程项目的一个很好的候选人，物联网流量卡，与谷歌工程副总裁Ben Treynor对SRE的描述非常吻合："从根本上说，这是当你要求软件工程师设计一个操作功能"

但是我们是一个网络工程师团队，是思科和Juniper路由器等方面的专家。我们对编写软件了解多少？当时，不是很多。除了有网络运营背景外，我们没有把自己的问题当作一个等待构建的软件系统来考虑。

我们决定冒险：我们要编写软件来解决我们的问题。作为负责网络的工程师，我们真的很担心，升级路由器的人可能会用光，而这对公司来说是一个更大的风险。几个月后，我们得到了一个原型工作，依靠我们在相邻的SRE和开发团队中的合作伙伴征求意见。

我们运营小组的高级领导授权我们进一步推进项目，但并非没有仔细探索所涉及的风险。自动化可以在创纪录的时间内完成对人类来说很费劲的工作，但如果它失败了，就会造成创纪录的损害。作为谷歌内部最后一个采用SRE方法的领域之一，我们能够利用过去在机器世界的经验。

一开始，失去连接到网络设备的直接经验而让软件来做这件事感觉很不自然，对于那些没有参与过软件项目的网络工程师来说更是如此。任何用软件代替人工操作的人都会遇到这种感觉。最终，我们的坚持得到了回报，通过公布我们的设计和演示系统的安全功能，我们赢得了网络运营小组其他成员的信任。

12个月后，返利app可信吗，永久免费自助建站软件，让网络工程师手动升级路由器成为例外，而不是常规。事实上，该系统更加可靠，手动升级需要一些理由。在很短的时间内，我们构建升级系统的小团队发现，他们处于解决一系列非常新的问题的最前沿：扩大系统规模和进行可靠性工程。

一旦我们达到这一点，我们已经证明SRE原则可以应用于我们的领域。基本上，没有什么特别的网络，使他们不适合SRE.

不久之后，更多的工程师跟着，直到大约10%的团队成功地建立系统，自动化劳动。我们建立了量化影响的指标，但很明显，我们仍然无法跟上不断增长的增长所带来的辛劳。

在18个月的时间里，我们的团队负责人计划分成四个独立的SRE团队，每个人负责谷歌网络基础设施的不同部分。而不是跟随太阳，这意味着在工作日结束时，三个地点中的每一个都将把问题交给下一个地点，每个小组将分布在两个地点，每个地点都有一个12小时的值班时间。