转载

不再需要传统运营了

　　英文原文：Guest View: Traditional Ops is no more

译者注：为了更好地理解本文，请先了解 DevOps 的意义。

　　大约 10 年前，Amazon 的首席技术官（CTO） Werner Vogels 出色地揭示了公司怎样从传统的 web 运营主导部门转变为由开发人员部署自己的代码。

　　“传统模式是，一堵墙隔开了开发和运营，你把软件带到这里，扔到墙那边，然后就忘记了。不是在 Amazon。你开发软件，你运行软件，”他说。

　　现在，对于任何地方的 web 开发团队，他的话是仍然有道理。10 年前难以想象的一个工作流，现在正成为现代团队的标准，这是由于今天有着强大的、可靠的、以及易于使用的云基础设施服务。因为有了新的工具，比如 Amazon Web Service、Heroku、DigitalOcean、GitHub、托管的持续集成（CI）等，开发人员现在可以编写、测试、部署和运营大规模 web 应用程序，而不用和传统运营团队或系统管理打交道。

　　这是一片新领域，整个角色正在退出，开发人员需要快速获取新的技能组合来适应。和某个行业的任何巨大变化一样，那些无法适应的人将被抛在后面。

　　优秀的 CTO 们需要成功地把他们的开发人员转移到新的现实环境来。当引入“你编写、你发布、你修复”的工作流时，每个开发人员将对他或她发布的代码负责。明白了这一点，当发布代码时，你就是为你负责的代码添加。这种方式的无意识的影响就是，它给发布代码带来了更大的焦虑，因此减少了产出。

　　对于 CTO 来说，软件产出已经是主要问题了。2012 年剑桥大学的一项研究表明，开发人员几乎要花一半时间（49.9%）调试代码。我就是一名开发人员，我敢说这个数字是相当精确的——对于大型组织，它可能有些保守。

　　如果适合的文化和工具到位了，那么让开发人员运营和修复他们自己的代码将是一项优秀的业务用例。对于当今想跟上业务快速移动步伐的组织来说，迁移到这种模式，有着重大意义。比起任何非开发人员或传统运营人员，开发人员能够更加快速地修复代码，因为代码是他们写的。对他们自己的代码负责，可以增加总体代码质量，以及降低总体调试成本。

　　那些让他们的开发团队成功地做运营工作的公司，将迅猛地前进，不过，这不得不从文化转变和配套的工具集开始。在开发团队怎样工作上，外包基础设施是一种文化范型的转变。

　　从业务视角看，这种转变有着潜在的深远影响，但它不仅仅是马上见效。把基础设施外包给云，除了需要重新分配责任，还给开发团队提出了重大的文化挑战，因为开发人员现在有两份工作：写代码，以及确保故障修复。

　　透明和责任，对于成功管理这种文化转变是至关重要的。工作流中的这种改变意味着，开发人员不仅仅要从上午 9 点到下午 5 点赶写代码，还要从下午 5 点到早上 9 点值班。那些凌晨 2 点的 bug 通知对于开发人员来说，是不受欢迎的时间段，尤其对于某个同事失误引起的 bug，不过他们需要马上解决。

　　开发人员一天多次，来来回回地部署代码，因此，对于开拓这个发展中环境的开发团队来说，关于什么被发布了、谁发布的、运行情况等方面的、更好的工具和知识分享，将是关键的。为了让开发人员判定这些新的责任，团队需要在稳固的调试工具和协调工作流上加大投入。

　　还有，当宕机发生时，拥抱没有责备的事后检讨和鼓励透明也是重要的，因此每个团队成员才能从所犯的错误中汲取教训，而不用在乎谁犯的错误。

　　转变的好处：更便宜的基础设施、更少的维护、更快的开发周期、和每天多次部署。云基础设施通过提供可靠的基础来消除过去的大部分运营工作，在策划这次巨大变化中发挥着协调作用。云的稳定性，大部分是不成问题的，由基础设施提供商拥有，大多数宕机都是由于开发人员的代码修改引起的。

　　Instagram 在 Amazon Web Service 云上完全建立了它的社会化分享图片服务。在它被 Facebook 收购之前，Instagram 赢得了最大运行时间的声誉，甚至在其规模增大到应对数千万用户的时候。Instagram 联合创始人 Mike Krieger 最近说，在开发公司服务时，公司主要的运营问题都不是因基础设施引起的。“我们问题的头号原因是我们自己，”他说。

　　换句话说，陈旧的方式正在消失，无论我们喜欢与否，现在，运营负担正压到开发人员身上。今天的运营就是要确保代码库正常运行；这是每个开发团队能够体会到的。

正文到此结束