04 | 标准化体系建设（下）：如何建立基础架构标准化及服务化体系？

本篇的重点，标准化的目的是为了更好地提供服务，而服务化又是标准化的技术落地形式。

亦如编程的过程就是了解工具掌握工具规范化使用工具的过程，编程中的自由并非为了达到目的就可以胡作非为，而是在一定的约束下，通过有限且有效的步骤来实现业务逻辑，而这些约束或者是编程范式，或是设计模式，或是代码规范，总之想要提升效率就需要制定标准规范，遵守契约，以流程化，标准化的方式进行高效的协作。在架构中规范协议，制定标准，避免过多精力耗费在组织之间的协作沟通上，从而提高研发效率。

服务化也是运维能力的输出，当然它的核心目的是标准化的落地。

正在梳理公司的运维标准及规范。公司以前也有，就是比较零散，现在发现缺乏一个方法，把这些零散的文档串起来。就是说，希望能找到一个方法，能整理出我们需要哪些标准规范，具体要求是什么。缺少的，我们补充；不达标的，我们完善。请问有什么建议吗？

基础架构的服务化平台开发，目标是平台自助化，让开发依赖平台的能力自助完成对基础组件的需求，而不是依赖运维的人，这里需要运维要有强大 的研发能力，这块需要哪些技能呢

不知道用java技术栈能否开发出您说的这类运维平台，而无需为每个被管理对象安装一个代理，比如：开机关机，当然是针对虚机或docker，还有控制redis的启停啊，rabbitMQ的启停啊，当时的消息的消费情况什么的，等等，相信这个团队要有相当的技术实力，比如阿里云的所有服务都通过网页可以操作

关于基础架构标准化的理解，个人并不赞同文中的观点。鉴于作者在行业的影响力较大，不希望偏颇的观点被广泛传播，激化开发与运维的矛盾。在此，表达个人的观点。希望辩证讨论。 分歧不在于：是否需要标准化？当然需要标准化； 分歧在于：什么是标准化？如何标准化？ 第1种理解：文中理解的标准化是选型。既基础框架、中间件、消息队列、缓存的选型；比如：文中提到的尽可能选择一款关系型数据库mysql，而尽量不要选择oracle/sqlserver/ mariadb等；再比如：微服务框架选择sprint cloud，而非选择dubbo、istio等。 第2种理解：而我个人理解的标准是接口标准化。不是限制了中间件的选择，而是运维可以对微服务框架、数据库、消息队列等运维对象，定义服务管理的接口（API），不同的中间件适配运维的API。例如对于微服务框架，定义服务启停、扩容、缩容、限流等API，开发团队可以采用不同的微服务框架（dubbo、sprint cloud、istio等），但采用的框架，必须开发API适配模块，对接运维的自动化。 之所以标准化，应该是第2种选择，基于现实情况的考虑： 1）应该包容应用的多样性，在绝大部分的企业中，应用是多样的。自研的系统、外购的系统、合作开发的系统，加上不同团队的技术栈不同，采用了多样的中间件。不能说，你这个应用没选择Mysql，不满足标准化要求，另一个系统采用了dubbo，而不是sprint boot，也不满足标准化要求。不满足标准化，所以不归运维管理，需要应用去改造，这是非常不合理的。 2）所有的框架、中间件等开源都在快速的发展。以微服务框架为例，典型的有dubbo、sprint cloud，而当前service mesh快速发展，istio、Envoy等进步迅猛，消息队列从kafka到pulsar等发展迅速。开发团队经常因为标准化的问题，跟运维团队发生矛盾。 因此，请作者慎重的思考标准化的规范，特别是文中“参与制定基础架构标准化，并强势地约束”观点。从哲学的角度看，统一性与多样性需要找到一个平衡。另一方面，标准化基于接口（API）更加开放，而非是排他性的选型。

我们目前做的大部分工作就是基础架构组件的服务化工作，感觉基础架构组件的标准化工作大部分是一带而过的，并没有形成很强的约束，这也造成了虽然服务化的工作做完了，基础架构组件也通过API对外提供服务了，但是在运维层面，会收到业务方各种各样的需求，每天都要花很多精力在处理这些事情。 举一个不是很恰当的类似，标准化的过程是一个设计的过程，服务化的过程是一个实现的过程。没有进行充分的设计，就去实现，到最后会发现各种问题。 标准化的过程，有2个建议： 1. 标准化并不是一个团队就可以搞定的，必要的时候，需要把业务方拉进来一起讨论，毕竟最终的需求是业务提出来的。 2. 标准化完成后，一定要及时发布给所有业务方，并标明服务的各种约束，这样业务方在做技术选择以及技术架构设计时，也可以充分考虑哪些能力是基础架构组件服务可以提供的，哪些是不能提供的，从而避免了后面吗不必要的扯皮。

看了文末总结运维的职责，这是否可以理解为，运维应当掌握与开发人员相差不多的编程能力，并且还要积累相对多的对业务的理解，才能满足标准化以及基于标准化推动自动化时，对人员能力的基础要求。

对象、属性、对象之间（应用与资源、应用和应用）的关系、针对对象的运维场景。 基础架构标准化（研发和运维共同的责任）。 基础组件架构统一。（如用业务的数据库类型种类） 技术选型（开发语言，统一的开源组件） 基础组件的服务化（建设paas平台，场景化自动运维） 运维的职责。 参与制定架构标准，并对标准强制约束（运维研发配合）-> 效率提升 paas平台开发，目标是平台自助化。解放运维对基础组件的维护。