一说起运维，很多人通常会将其工作范畴与服务器维护、网络设备配置、软件安装维护等工作联系起来，认为这就是运维；而开发经验更多、或对开发理解更深的人知道，除此之外，开发所依赖的各种基础设施的搭建和维护，以及支持规范的开发过程、提高开发效率的各种系统或工具的搭建、管理、维护，甚至一些与此相关的开发工作，也是由运维来承担的。
这些说法虽然没做，但是单薄了点，尤其对于新手和外行而言。这放在过去，影响可能不会特别大，但现在微服务架构的背景下，如果不能很好的理解运维，微服务架构的设计和实现也会举步维艰。
Gevin最近结合自己的工作经验，参考了一些书籍和运维大牛们的观点，梳理了我目前对运维的理解，和大家分享一下，欢迎交流。
运维的意义
通俗的说，在系统开发阶段，运维要支撑开发、协助提高开发效率和维护研发基础设施；在系统上线后，运维要保证系统的正常运行。这是大家公认的运维的意义，我最近看大牛的分享，发现从“公司利益”的角度谈论运维，是描述运维意义的一个更好角度，也能描述的更加清楚。
一个公司对于研发的诉求通常是全力实现业务需求，并将需求尽快发布上线以实现商业上的收益。但在开发过程中，开发工作可分为两类：一类是专注于业务需求的开发和测试工作，另一类是基础工具或模块的开发，比如中间件开发、稳定性开发、工具开发、监控开发、IaaS 或 PaaS 平台开发等。前者是公司所有人都认同、也会关注的工作，后者是支撑前者乃至整个产品稳定的基石，只要稍加解释，公司所有人也应该能认同这部分工作量，也应该会支持相关的开发工作（否则就要以产品的不稳定为代价了）。
然后我们再梳理一下研发工作，就会发现，除了业务开发和测试外，其他研发工作都是为软件开发过程或软件的运行维护服务的，其作用是提升研发效率和稳定性，进而降低成本。虽然这些工作没有全部定义在运维角色上，但这些工作职责已经属于运维了。
关于运维，大牛还有这样的观点：
运维能力是整体技术架构能力的体现，运维层面爆发的问题或故障，一定是整体技术架构中存在问题，割裂两者，单纯地看技术架构或运维都是毫无意义的。
但是，我们在绝大多数情况下，忽略了这个隐藏在软件生命周期中真正的运维范畴，而是简单直接地从软件生命周期分段的角度，生硬地给开发和运维划定了一条界限。
也正是这样一个简单直接的界限划定，让我们将运维仅仅局限在了服务器维护、网络设备配置、软件安装维护这些最末端的职责上，而我们又期望运维这个角色能够掌控全局，不要在这个阶段出现任何问题。这就很像临渴而掘井，是不现实的。
运维思路上的转变，远比单纯提升运维技术更有价值，而运维真正的价值应该跟研发团队保持一致，真正聚焦到效率、稳定和成本上来。
运维与软件开发过程
本节从软件项目开发的角度，对运维如何支撑开发和项目过程，再详细说明一下。
如上图，通常一个软件项目的过程可以分成三个部分：技术、过程和基础设施。其中，技术这条线上，项目团队在技术leader的带领下，明确目标，分解任务，跟进项目过程，把控项目节奏；过程这条线，让团队在某一个软件开发方法的指导下，一步一步把软件做出来的过程；而基础设施这条线，列出了支持软件开发过程必不可少的一些基础设施。
我在《如何做出用户满意的产品》一文中，整理过敏捷开发方法的一些思想，其中的“提早集成、频繁集成”、“提早实现自动化部署”、“使用短迭代，增量发布”等要求，都是软件开发中，基础设施这部分要承担的工作，按上文说法，都是运维。
有一个说法是，软件开发中，增加一个功能特性的成本，并不单单是为这些功能编码所花费的时间，还应该包含对将来扩展所设置的障碍。如果基础设施不到位，会给功能开发带来很多额外的障碍，而大部分这种障碍都能通过加强运维的投入而避免的。
所以，运维不到位，开发也不会顺利。
运维与微服务
现在微服务大热，很多团队都开始号称自己采用微服务架构。而微服务架构，对运维提出了更高的要求。
微服务架构使得架构的复杂度大大增加，对运维团队而言，维护微服务架构的系统，不仅要维护其业务应用，还要维护支撑起业务应用的基础设施，随着系统规模的增大，用户的增加，高并发、高可用等要求提上日程后，这两方面内容会交织在一起趋于更加复杂，这种复杂度靠人力是难以掌控和管理的，为后续的交付和线上运维带来了极大的难度和挑战。 所以，微服务架构要求运维打造一套工具支撑体系来支持相关工作，架构本身也要在支持业务功能之外，包含开发、交付和线上运维阶段所需的基础维护能力。比如服务上下线、路由策略调整、并发数动态调整、功能开关、访问 ACL 控制、异常熔断和旁路、调用关系和服务质量日志输出等等，这些在架构设计时要考虑，而其实现是在运维工具和服务平台上。
微服务架构模式下，运维已经成为整体技术架构体系中必不可少的一部分，而且与微服务架构相关的体系是紧密相连不可拆分的。
微服务架构模式下的运维思路一定要转变，一定要将视角转换到应用这个维度，从一开始就要统一规划，从一开始就要将架构、开发和运维的工作拉通了去看，这一点是与传统运维的思路完全不同的。
注
本文的引用内容，均来自极客时间的专栏《赵成的运维体系管理课》。
注：转载本文，请与Gevin联系
欢迎关注我的微信公众账号
