前面几周，我们介绍了Netflix为什么没有运维岗位、应用运维标准化、基础服务标准化以及从应用生命周期的角度如何进行运维建设等内容。这一周我们就来聊聊在组织架构和运维转型方面的话题。
专栏的第一篇我们就介绍了Netflix的云平台组织架构，你应该可以发现，Netflix其实已经给我们提供了一个非常好的思路和方向，就是在提供基础服务能力的同时，提供对应的自助化运维能力。也就是说，开发人员可以在这样一个平台上完成自己想要做的任何运维操作，而不再依赖运维的人。
我们最应该学习和借鉴的，也恰恰是我们绝大多数团队都会忽略的，就是要做好运维和整个技术架构体系的融合，一定不要割裂两者。同时，还要注意不仅仅是促进组织架构层面的融合，最重要的是要促进职能协作上的融合。
应该怎么理解呢？
我先撇开组织架构，大致说一下我的思路。开篇词中我提到，运维能力的体现，一定是整体技术架构能力的体现。所以，要想做好运维就一定要跳出运维这个框框，从全局的角度来看运维，要考虑如何打造和体现出整个技术架构的运维能力，而不是运维的运维能力。这一点是根本，一定要注意。如果我们仍然片面地从运维的角度看运维，片面地从运维的角度规划运维，是无法走出运维低价值的困局的。
当我改变了这个认知后，我的出发点就回归到了效率、稳定和成本这三个对于研发团队来说最重要的目标上来。从运维的角度来说，能够与这三个点契合的事情，我总结了以下五个。
1. 运维基础平台体系建设
这块主要包括我们前面提到的标准化体系以及CMDB、应用配置管理、DNS域名管理、资源管理等偏向运维自身体系的建设。这一部分是运维的基础和核心，我们前面讲到的标准化以及应用体系建设都属于这个范畴。
2. 分布式中间件的服务化建设
在整个技术架构体系中，分布式中间件基础服务这一块起到了支撑作用。这一部分的标准化和服务化非常关键，特别是基于开源产品的二次开发或自研的中间件产品，更需要有对应的标准化和服务化建设。这也是我们无意识地割裂运维与技术架构行为的最典型部分，这里容易出现的问题，我们前面讲过，你可以回去再复习一下。
3. 持续交付体系建设
持续交付体系是拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分。这个部分是整个软件或应用的生命周期的管理体系，包括从应用创建、研发阶段的持续集成，上线阶段的持续部署发布，再到线上运行阶段的各类资源服务扩容缩容等。开发和运维的矛盾往往比较容易在这个过程中爆发出来，但是这个体系建设依赖上面两部分的基础，所以要整体去看。
4. 稳定性体系建设
软件系统线上的稳定性保障，包括如何快速发现线上问题、如何快速定位问题、如何快速从故障中恢复业务、如何有效评估系统容量等等。这里面还会有一些运作机制的建设，比如如何对故障应急响应、如何对故障进行有效管理、如何对故障复盘、如何加强日常演练等等。同样，这个环节的事情也要依赖前两个基础体系的建设。
5. 技术运营体系建设
技术运营体系也是偏运作机制方面的建设，最主要的事情就是确保我们制定的标准、指标、规则和流程能够有效落地。这里面有些可以通过技术平台来实现，有些就需要管理流程，有些还需要执行人的沟通协作这些软技能。
最终通过这样一个规划，我把团队以虚拟形式重新规划了不同职责，分别负责基础平台体系、分布式中间件服务化体系、持续交付体系和稳定性体系，基本就是上述的前四件事情。
对于最后一个技术运营体系，这一点作为共性要求提出。我要求团队每个成员都要具备技术运营意识。具体来说，就是要能够有制定输出标准的意识和能力，能够有规范流程制定的能力，同时能够将标准和流程固化到工具平台中，最后能够确保承载了标准和规范的平台落地，也就是平台必须可用，确实能给运维团队或开发团队带来效率和稳定性方面的提升。这些对个人的要求还是比较高的，要有一定的规划、设计和落地能力，能具备一整套能力的人还是少数，目前这块还是靠团队协作来执行。
上面的这几件事情，并不是由运维团队内部封闭来做。还是我们反复强调的那个思路，要站在怎么能够打造和发挥出整个技术架构体系运维能力的视角，而不仅仅是发挥运维团队的运维能力。所以这些事情的执行可以理解为是由运维团队发起，与周边技术团队协作配合来完成的。
所以这些事情都需要跨团队协作。一方面运维团队要主动出击，去沟通，去推进；另一方面，必须能得到上级主管甚至是更高层技术领导的支持，所以这里要求技术管理者必须要有这个意识，促进这样的组织协作方式变革，如果技术管理者意识不到或者支持不到位的话，运维在后续的推进工作中将会遇到非常大的阻力。
下面来分享下我们目前正在尝试的一些调整。
我们运维所在的平台技术部门，包括了分布式中间件、虚拟化技术、稳定性工具平台以及大数据几个子部门。当我们发起并推进上述工作时，就需要与这些团队联合协作，朝着某个目标共同执行。下面我们来看看细分的情况。
1. 运维基础平台建设
这块大多数的工作会由运维来完成，因为这是运维的基础，也属于整个技术架构比较关键的基础平台之一，这一点我们在讲应用和集群服务管理时已经介绍过。
2. 分布式中间件服务化建设
这个部分我们就需要分布式中间件团队的配合。我们可以一起制定各种使用标准、规范和流程；中间件团队负责提供运维服务能力的接口；运维团队根据用户使用的场景进行场景化需求分析，并最终实现场景，同时负责标准和自助化工具平台的推广和落地。
3. 持续交付体系建设
这一部分也会涉及多个团队的协作。在资源使用上，我们前期会用到KVM，那么如何快速交付KVM资源，就需要与虚拟化技术团队协作。现在我们在尝试容器方案，涉及到镜像制作、网络配置以及对象存储这些底层技术，一样会与虚拟化团队配合，在资源交付效率和利用率上都有很大提升。同时，还会与中间件团队协作，因为在应用发布和扩容缩容过程中，就会涉及服务上下线，这就要与服务化框架配合，服务化框架提供底层运维服务能力，而运维要做的就是通过中间件运维能力的封装整合，进而实现用户使用的场景化需求。
4. 稳定性体系建设
这里会涉及一些链路埋点、限流降级、以及开关预案等一些技术方案需求，通常会有这样一个专门的稳定性工具团队，对外输出一些稳定性保障能力，比如一些稳定性通用SDK的开发，后台日志采集分析以及数据计算等等，这些事情会对技术能力的要求比较高，需要具备较强开发能力的人来做。所以，运维在这里发挥的作用一个是上述提到的场景化实现能力，再一个就是稳定性能力的落地，或者说是运营能力。稳定性工具提供的多是能力和支持，最终要在业务层面真正执行，就需要运维和业务开发共同来执行。比如一个应用上线，是否具备关键接口的限流降级能力，是否具备熔断能力，是否满足上线的性能及容量要求，这个工作是需要运维深入每个业务，根据不同的业务场景和实现情况，一个个具体落地才行。所以，整体上对运维技术运营能力的要求就会非常高。
运维在这个过程中要发挥的最关键作用就是通过用户使用场景的分析，将各项基础服务封装并友好地提供出来，并确保最终的落地。方式上，或者是通过工具平台的技术方式，比如分布式中间件基础服务；或者是通过技术运营能力，比如稳定性能力在业务层面的落地。
运维在这个过程中，就好像串起一串珍珠的绳子，将整个平台技术的不同部门，甚至是开发团队给串联起来，朝着发挥出整体技术架构运维能力的方向演进。
上面是我们从团队需求和运维价值呈现层面成立的虚拟组织，从实际的人员管理以及技能维度来划分的话，我们和其它互联网公司的运维团队差别不大，基本会分为如下几个岗位：
这个实体的组织架构，相当于是从技能层面的垂直划分。基础运维更擅长硬件和操作系统层面的运维；应用运维可能更擅长业务稳定性保障、疑难问题攻关以及技术运营等；数据运维就不用多说了，DBA本身就是专业性极高的一个岗位；运维开发则是支持上述几个岗位日常运维需求的，是否能将人力投入转换成工具平台支持，就看这个团队的能力。
而前面所说的从价值呈现层面进行的虚拟团队划分，则是将上述几个实体团队技能上的横向拉通，让他们重新组织，形成技能上的互补，从而发挥出更大的团队能力。
实体组织架构，相当于一个人的骨骼框架，但是价值呈现层面的虚拟组织，就更像是一个人的灵魂，体现着这个人的精神面貌和独特价值。
这个过程中，必然会对运维的技能模型有更新、更高的要求。
今天我为你介绍了我们正在实践的一些运维组织架构方面的内容。后来当我翻阅《SRE：Google运维解密》这本书时，发现如果按照书中的章节目录进行分类的话，基本上都可以与前面我介绍的部分对应起来，这也更加坚定了我们要按照这套组织模式运作下去的信心。
同时，我们也要明白，业界没有一劳永逸的组织架构，也没有放之四海而皆准的组织架构标准，更没有万能的可以解决任何问题的组织架构设计，这里的关键是我们如何能够发挥出团队整体的能力和价值，而这一点又需要我们不断地与自己所在团队和业务特点去匹配和契合，这是一个不断变化的过程，也是需要持续调整的过程。
所以这对技术管理者要求会比较高，应该如何不断地去匹配和契合这个最佳价值点，同时如何统筹调度好团队中不同类型的技术资源并形成合力，是非常重要的。
你的团队在实际过程中遇到过哪些问题，你有怎样的经验和观点，欢迎你留言与我一起讨论。
如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！
评论