一、架构实施和架构运维

我们制定或约定了架构标准，接下来就是架构的实施过程，架构实施应该怎么理解呢？我大致列一下过程应该就比较清晰了：

1、业务分析过程中，职责明确的业务模块从整体中拆分出来，比如用户、商品、交易、支付等等业务逻辑；

2、从服务化的角度拆分，这样一个大的业务逻辑可以拆分出更细的服务化模块，以商品为例，会有商品详情、库存、评价、价格、标签等等，如果继续细分可能还会有各种读写逻辑的功能化的服务拆出来，拆分的原则啥的我们这里不细说，这个基本取决于业务架构师的判断标准；

这个阶段拆出来的一个个模块，就是我们所说的应用了，这时就要开始应用名的定义，至此，一个应用的生命周期开始启动。

3、应用生命周期启动后，应用相关的信息就需要在运维系统内生成了，也就是我们所说的CMDB和应用配置管理相关的额信息。（应用相关的信息见文章《如何打造一个以应用为核心的运维体系》），重要的跟运维相关的如应用对应的Gitlab地址、基础软件模板和配置、以及对应的开发、测试和线上的资源需求；

4、根据上面拆分出来的应用，开发同学就要根据我们之前约定的架构标准，开始选择标准化的框架了，比如分布式服务化、消息、缓存、DB中间件、以及稳定性和一些第三方的SDK包等等；

熟悉开发的同学都很清楚，上面这些框架选定好之后，按照Spring Boot的模式，可以自动生成整套的代码框架，就省去了手工引入各种二方包、三方包和一些固定的配置，也就是Spring Boot的“约定大于配置”的思路。这个也是目前绝大部分团队的选择的微服务的应用模式。
这样开发同学可以把更多的精力放到业务逻辑的实现上，而不是各种各样的框架引入和配置上面。所以，不仅仅是运维自动化，代码开发也一样在朝着更加自动化的方向发展。（再进一步，Spring Cloud的体系则更加完善）

5、启动业务代码开发后，就该进入到持续交付阶段了，具体可以看《XXOps实践：持续发布和部署》，不过前提是得先有持续交付的体系；

6、业务上线后，就进入持续运维和反馈阶段，如监控数据的分析、稳定性保障、核心应用和链路的容量评估、应急预案的制定和演练、强弱依赖的分析，以及从用户提交角度的数据分析和保障措施等等；

7、应急事件和故障的响应、处理及回溯机制，因为故障没有办法100%的避免（但是应该杜绝低级的人为失误和重复错误），我们要做的是故障的快速甚至是提前发现、业务的快速恢复，以及故障后的回溯和改进；

按照《聊聊架构》书中的架构生命周期的划分，上述过程，我们认为是架构的实施阶段，不过1-4，更多的可以看成是开发为主进行实施的，5-7阶段则应该更多的是运维为主的阶段（如果持续交付做的好，其实5也是可以以开发为主）。

不过，我的理解应该将5-7这个阶段拆分出来，定义成架构运维或架构看护阶段。图示下来，就是如下过程：

从上图我们就可以看出，运维应该要体现的作用和价值了。

二、运维的角色转变和价值体现

1、技术产品

产品是指能够提供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念和他们的组合。（摘自百度百科）

整个运维过程中，运维一定要转变被动响应式的工作方式，要主动求变，其中最重要的就是树立起产品意识，将日常的人肉的、繁琐重复的工作不断的总结和提炼。

比如，是不是能够把自己原本靠人工完成的很多工作转化成需求？是不是能够把日常工作中运维和开发的痛点转化成需求？是不是能够把当前系统存在的问题和隐患找出来，在解决的过程中，经过分析总结提炼成需求？

当需求提炼出来之后，是否能够准确的传递给工具开发团队，并跟工具开发团队一起把需求真正的落地实现？

以上过程，就是将运维的人肉能力转化为平台能力的过程，比如持续发布，没有发布系统之前，完全靠人肉堆，开发、测试和运维一起上，还经常出问题。但是有了发布系统，将人做的事情转交给平台自动化去做，最终满足开发快速将代码发布上线的需求。

结合上面对产品的定义，看看我们上面做的事情，是不是就是一个技术产品的工作呢。当我们具备了这个意识，能有更多的工具做出来，逐步形成体系，我们的工作是不是变得更轻松了呢？

2、技术运营

运营的目的，和产品经理核心的不同是，要实现扩散，爆发，增长，收益等等。(摘自知乎)

通过上面的技术产品的工作，如果可以做出一些有针对的工具和平台来，但是仅仅有工具和平台就够了吗？不过，远远不够，为啥这样说呢？

a、推广落地，工具做出来了是第一步，得要有人用，这就需要去推动落地。（跟业务上做出一个产品来，要去找渠道推广，要吸引流量过来，并最终产生经济收益是一个道理。）当然，我们在内部倒不必吸引用户来用，因为我们的技术产品更多地是标准、流程和规范的载体，既然大家之前都遵守了这套标准体系，那就必须使用（使用之前做些小范围的试用还是必须的），所以这个过程是可以强势一点的。比如线上仅保留发布系统一个变更入口，其他变更权限全部收回等等。

b、线上运行数据分析，应用上线或者每次变更上线后，线上运行的情况咋样，容量有没有降、RT有没有上涨、监控有没有异常，业务量上是否有激增、用户体验有没有下降，用户和客服的反馈如何等等。以上这些维度和指标就需要一张张的数据报表呈现出来，通过数据分析来指导我们要做出哪些优化和调整。（想想看，业务运营是不是也非常关注业务数据报表的）

c、过程改进，工具更多的是一个执行角色，但是工具的使用是要配合大量的标准和流程一起来运作的，比如说持续交付，里面就会涉及持续集成，再往细里讲，代码分支应该如何合并，出现冲突后应该如何解决，自动化测试需要哪些用例，用例等级如何定义，测试验收的标准是什么，构建失败应该怎么处理，当团队成员无法达成一致的时候，应该如何决策等等；再比如，b中提到的遇到的种种上线后的情况，应该对应什么样的机制处理下去，这些都是技术运营过程中所面临的问题。一方面要先有对应的流程机制确认下来，大家共同遵守，另一方面，执行过程中，如果有导致效率下降或者有更好的措施的时候，这个时候就需要过程上的改进。

我们面临的业务场景再不断变化，技术趋势不断发展，就决定了技术运营过程一个持续改进的过程。

在腾讯，运维被定义为技术运营，我觉得还是很贴切的。我在很多大会上听海外的华人工程师分享，Operation这个词都是被直译成运营。所以，我也很能理解老王在多次大会上都说，国内也不知道谁，把IT Operation，IT运营这么高端的一个词汇，给硬生生地非翻译成了运维这么个意思，确实无奈：）。
Anyway，不纠结。因为运维所发挥的技术运营的作用，这个能力其实才是运维的核心价值和转型的关键。

3、技术服务

我觉得两层含义，一个是一定要有服务的心态；另一个，提供解决方案，还是举个栗子：

比如，我们在线上运维过程中，发现有一块相对独立的业务，体量越来越大，随着用户的增多从一个非核心的业务变成了一个核心业务。但是，这个业务是用C++来做的，架构上是分层架构，每层都是通过配置IP的方式进行接口调用，还有跨层的调用，调用逻辑很不清晰。遇到的比较突出的问题就是效率和稳定性：

a、发布的时候，就没法做到服务发现，要一台台改配置将流量迁移走，然后手工执行发布脚本同步代码，然后再将配置改回来进行验证是否成功了，随着机器数量越来越大，开发就吃不消了，太麻烦；

b、出现故障，唯一的手段就是回滚、重启、干瞪眼，类似降级、限流或开关的稳定性手段都没有；

c、线上容量也没法评估，发布个版本发现容量不够，就扩容，而不是真正去找一下性能下降的原因；

这个时候发现了问题，我跟团队一起去做的事情，找到对方的主要负责人和其主管（或者对方来找我们），大家一起坐下来，针对现在的问题和痛点，看如何改进，比如发布效率低，那发布的过程步骤是什么，我们一起看看什么地方可以改进和提升，比如有写死IP的情况，那是否可以做到分配从代码中分离，或者考虑服务发现的方案（服务发现考虑过，但是实现成本比较高，现在做需求还做不完），那是否可以利用现有的服务化框架，然后给中间件团队提需求尽快支持C++的分布式服务呢？嗯，这个可行，我们一起找！

稳定性有问题，我们现有的稳定性系统支持开关、降级、限流，最近碰到的问题如果有降级措施的话，是可以将故障快速隔离的，然后介绍下现有稳定性的解决方案，评估了下，嗯，可以搞。

最后的结果是，双方共同配合进行改造，将一个维护效率和稳定性不高的业务大大改进了。

这个时候，运维虽然不是代码的实际开发者和改造者，但是通过解决方案和思路上支持，推动了业务架构上的演进。这里也不是开发同学能力水平不行，而是业务需求量大，实在没有这么大的精力去端到端关注全面的东西，但是两者一旦都向前走一步，擦出基情的火花，事情效果很显著了。所以我们配合一定要有共赢的心态，而不是你是你我是我一定要分的很清楚，当然这个过程中，我建议运维应该向前多走几步。

三、思考一下

技术产品、技术运营、技术服务，从这三个角度来做运维，运维还是原来那个运维吗？个人的成长空间、承担的职责以及价值的体现，是不是会大不一样呢？欢迎留言讨论。

本文转载自成哥的世界公众号。

原文链接：https://mp.weixin.qq.com/s/jYQXJ_sZEhSs9o5Y-fFW4Q

创作场景

运维需不需要懂产品和运营呢？