今天是系统管理员感谢日。请转向您身边最亲爱的系统管理员，并务必感谢他们的工作。
“运维结束了。”
“系统管理员？ 那太老派了。”
“所有优秀的工程团队都在通过自动化消除运维。”
你经常听到这些话吗？ 我经常听到。人们喜欢说运维已死。当然，你可以将“运维”定义为各种令人不快的事情，其中许多确实应该消亡。但这既不准确，也没有特别帮助。
这是我对运维的定义：运维是你组织在设计、构建、扩展和维护系统方面的一系列技术技能、实践和文化价值观。” 运维是为用户交付价值的过程。运维是美好理论与顽固现实相遇的地方。
换句话说，运维是你完成工作的方式。这不是可选项。你交付软件，你就进行运维。如果业务是“为什么”，开发是“什么”，那么运维就是“如何”。我们都是相互交织的，我们都参与彼此的任务。
然后
二十年前，运维工程师被称为“系统管理员”，我们花费时间精心维护少数珍贵的服务器。然后 DevOps 出现了。DevOps 对很多人来说意味着很多事情，但对很多人来说，它无疑意味着：“亲爱的运维：学习编写代码。”
这对很多人来说是一个艰难的转变，但这是一件绝对的好事。我们需要 这些技能！复杂性正在飞速上升。没有自动化，我们就无法再完成工作，因此我们需要学习编写代码。这是不可避免的。
现在
自自动化时代曙光以来已经过去了 10-15 年，我们已经进入了其替代品的早期阶段：分布式系统时代。
考虑一下基础设施的流行趋势：容器、调度器、编排器。微服务。分布式数据存储、多语言持久性。基础设施变得越来越短暂和可组合，通过有损网络松散耦合。 组件的大小正在缩小，而数量却在成倍增加，两个方向都是如此。
然后在客户端方面：以移动设备为例，天哪。 （设备类型 * 固件 * 操作系统 * 应用）的组合爆炸本身就是复杂性的一次巨大飞跃。将其与分布式缓存策略、最终一致性、在客户端和服务器之间分割大脑的数据存储、物联网以及将关键组件外包给第三方供应商（实际上是黑匣子）结合起来，你就会开始明白为什么在不久的将来和现在，我们都是分布式系统工程师。
所有这些变化都要求思想和方法上的另一次根本性转变。你不仅仅是在编写代码：你还在构建系统。分布式系统需要更加关注可操作性和弹性。与我们可以使用监控和自动化管理的旧单体应用相比，新系统需要新的假设。
- 分布式系统永远不会“启动”；它们始终处于部分降级服务的状态。接受失败，为弹性而设计，保护并缩小关键路径。
- 你无法将整个系统记在脑海中或对其进行推理；你的生存或死亡将取决于你的仪表和可观察性工具的彻底性。
- 你需要强大的服务注册和发现、负载均衡以及组件之间每种组合的反压。
- 你需要学习集成第三方服务；许多核心功能将外包给你无法直接了解或影响的团队或公司。
- 你必须在生产环境中进行测试，并且你必须安全地进行测试；你无法启动大型分布式系统的暂存副本。
所有这些 有什么共同点？ 它们都是优秀运维工程的标志。而且它们也不再是可选项。换句话说：“亲爱的软件工程师：是时候学习运维了。”
运维：现在是每个人的工作
如果 DevOps 转型的第一波浪潮侧重于提升运维团队的编码能力，那么第二波浪潮则颠倒了剧本。如果没有持续关注分布式系统的可操作性、可维护性和可调试性，你根本无法开发出高质量的软件。没有运维基础，你就无法构建现代软件。
这种转型正在顺利进行中，证据随处可见——风险投资涌入“面向开发人员的运维”工具，开发人员必须分担随叫随到轮换的共识日趋成熟，软件工程师出现在传统上以运维为中心的会议上等等。面向开发人员的运维已正式到来。
这是一件好事！运维学习编写代码是好事，开发人员学习拥有自己的服务也是好事。所有这些变化都带来了更好的软件、更紧密的反馈循环，以及在仍然爆炸式增长的复杂性面前更强大的实践。
所以 不，运维不会消失。它只是看起来不像以前那样了。很快它甚至可能看起来像一个软件工程师。
2 条评论