gitbook/赵成的运维体系管理课/docs/1595.md

# 开篇词 | 带给你不一样的运维思考

    你好，我是赵成，来自蘑菇街。

大概在9月份的时候，我接到了极客时间团队的邀请，看是否可以做一个运维专栏，当时第一反应是略感兴奋，这还真是个意外的邀请。但是接来下我的反应就是诚惶诚恐，因为我自己写公众号也有一段时间了，深知持续高质量输出这个事情的挑战之大，特别是在输出专业文章上更是如此，所以当时一直拿不定主意。

我写公众号文章，很大程度是因为之前有过很多次公开演讲和分享，后来发现演讲所面向的受众和时间有限，分享的内容无论是在沉淀、传播以及深度上，都会受到很大的限制。总之，讲得不过瘾，索性就把一些我觉得还值得更深入探讨的话题和内容完完整整地写出来。

后来，在上海跟极客时间团队见面之后，他们给了我一些建议，因为之前的文章更多是针对一个个观点延伸出去写作，而专栏文章可以尝试更系统地输出，能够把一个运维体系讲透。这个建议从一定程度上打开了我写专栏的思路，后来我把内容规划了一下，感觉还是可以输出一些更有价值的内容，就启动了这个专栏的策划。

## 谈谈运维的价值

我们在大学的软件工程中就学过，从软件生命周期的角度看，软件开发阶段只占整个生命周期的20%~30%左右，软件运行维护阶段是最长尾的，这条规律放在当前这个时代同样适用。

在软件生命周期中，我们可以很清晰地划分出“开发阶段”和“运维阶段”，这个分界点就从开发完成代码开发，测试验收通过后，交付到运维手上的软件包开始，自此之后的阶段就是软件的运行维护阶段了。

一个公司对于开发的诉求应该是全力实现业务需求，并将需求尽快发布上线以实现商业上的收益。但是，在一个公司里，除了专注于业务需求的开发和测试角色外，还会有另外一大类开发，比如我们常见的中间件开发、稳定性开发、工具开发、监控开发、IaaS或PaaS平台开发，甚至专注于底层基础架构的内核开发、网络开发、协议开发等等。

这里请你跟我一起仔细思考下，我们会发现除了业务开发和测试外，前面所提到的那些技术岗位都是为软件生命周期中的运行维护阶段服务的，这些角色的作用就是提升研发效率和稳定性，进而降低成本。虽然他们并没有全部被定义为运维岗位，但是本质上他们是跟业务软件的运行维护阶段直接相关的。

所以，从运维的范畴上来讲，我认为，**一个研发团队内，除去业务需求实现层面的事情，其它都是运维的范畴**，这个范畴内的事情本质上都是在为软件生命周期中的运行维护阶段服务。

我之前在外部分享，一直表达的一个观点就是，**运维能力是整体技术架构能力的体现，运维层面爆发的问题或故障，一定是整体技术架构中存在问题，割裂两者，单纯地看技术架构或运维都是毫无意义的**。

但是，**我们在绝大多数情况下，忽略了这个隐藏在软件生命周期中真正的运维范畴，而是简单直接地从软件生命周期分段的角度，生硬地给开发和运维划定了一条界限**。

也正是这样一个简单直接的界限划定，让我们将运维仅仅局限在了服务器维护、网络设备配置、软件安装维护这些最末端的职责上，而我们又期望运维这个角色能够掌控全局，不要在这个阶段出现任何问题。这就很像临渴而掘井，是不现实的。

很显然，我认为，**运维思路上的转变，远比单纯提升运维技术更有价值，而运维真正的价值应该跟研发团队保持一致，真正聚焦到效率、稳定和成本上来**。

而这也正是我们很多公司和团队，当前所遇到的最大的痛点和问题。所以，在我的专栏里，我会针对这些痛点和问题分享一些我的思考。

## 专栏内容

我的专栏内容，会聚焦在分布式软件架构下的应用运维这个领域，更多的是我对运维的一些架构思考，主要有以下四个部分。

*   **应用运维体系建设**。这是我们做运维的基础，我会分享从标准化和应用生命周期开始，如何一步步建立运维技术体系和组织架构，以及整个过程中的沟通协作等方面；分享我们应该如何树立正确的运维建设思路。
*   **效率和稳定性等方面的最佳实践**。这些是运维价值的体现，我会围绕持续交付和稳定性建设两个方面，分享如何打造不需要任何运维参与的端到端交付过程，如何在实践中锤炼出稳定性保障体系。
*   **云计算方面的思考和实践**。云计算技术的蓬勃发展为我们的业务和技术提供了更多的可能性，利用好云这个平台将会是运维升级转型的必备要求。我会分享在混合云、云存储、静态化以及CDN上的实践经验，以及这些实践所带来的在成本和体验上的巨大收益。
*   **个人成长与趋势热点分析**。这一部分更多的会是我个人的一些思考，包括运维技术发展趋势、团队管理、个人成长、热门事件解析、观点碰撞等。

希望在这个专栏里，能够跟你有更多的互动和交流，希望我们在观点碰撞中共同进步。

最后，开卷有益，期望能够带给你不一样的运维思考。