自动化是架构平台部的灵魂，兼纠正马工错误

瑞典马工按： 在前文发出之后，之前在同程负责 HBase 的朋友们很不满，指出我的描述和事实不符。同程 HBase 的分发没有使用祖传脚本和脚本小子。两位朋友撰写本文纠正我的错误，同时阐发了他们对于自动化的理念。此处转发，供各位读者参考。
原文在 自动化：架构平台部的灵魂 ，各位可以订阅他们的公众号： 有兴趣的朋友还可以参考他们三年前的分享 同程旅行大数据集群在 Kubernetes 上的服务化实践 以下为正文。
瑞典马工昨天的文章 《基础架构部，还有必要吗？》 里面点名质疑在前司做的HBase集群服务是一个工单系统人肉祖传脚本运维的套壳产品，没有调查就随意猜测臆想他人产品，不妥。

实际上同程HBase集群服务申请的后台实现是将业务申请配置参数和集群配置模板合并后，基于k8s编排自动化拉起集群实例的过程，自动化能力丝滑，不存在“运维工程师接单去跑一个祖传脚本创建集群”的情况。

所以马工错了。 马工主要是吐槽国内工程师拒绝自动化，所以本人顺带 想给大家聊一聊基础架构的灵魂，自动化能力。 基础架构需要什么样的自动化能力？ 自动化要考虑ROI 。

集群服务数量不多，你花费很多时间考虑怎么运维自动化，节点上下线、服务如何自动化升级。开发一个月甚至几个月上线了一个运维自动化平台，再过几个月你算一算节省多少人效，发现节省的时间远小于平台开发的时间，由于基础架构不像业务研发投入很多测试人力，你可能还沦陷在平台bug功能上。相反你只是简单的维护几个脚本，把时间花在业务发展了，帮助业务快速完成他的需求，收益反而更高。

浪费资源，重复的自动化能力开发 。 基础架构分了很多模块，数据库、存储、大数据、中间件等，每个模块都有自己的用户系统，自动化运维系统，巡检系统，运维编排系统，硬件维修系统等等。大家都喜欢自己造轮子，自己的轮子一定是最好的，别人的轮子一定不合脚。基础架构并不像业务，迭代是第一生产力，没有时间让你去整合和思考。但是基础架构不一样，理想情况下，基础架构只需有两个平台，一个面向用户，一个面向自己。业务研发不需要在不同平台 跳来跳去 ，不同的平台带来的用户体验参差不齐。对内运维管理平台按照模块开发，复用通用的流程能力，每个模块开发自己的领域功能。 没有产品意识的自动化能力 。 国内有些公司做了一些IM机器人功能，让机器人拉取一下集群数据，让机器人拉一个集群日报给自己。这种功能设计应该没有好好的需求分析，拉取数据是发现问题并解决风险，为什么不发现问题直接自愈或者告警近实时检测通知。做一个表面功能给自己用，自己看下数据，再打开电脑处理问题吗？随着时间的流失，这些功能逐步废弃。

不支持可重试、可解释性的自动化能力 。 很多公司基架平台实现一个运维任务，如果任务出现失败，需要重新提交一遍任务，或者人工修补状态。绝大多数运维操作没有做到幂等，不支持可重试，存在二次运维变更故障的风险，这些开发平台的同学没有checkpoint机制的开发意识或者拆分运维操作的想法，可能只会在内存中写一个for循环完成所有运维操作。运维过程中产生的错误，不像业务一样用错误码标识并给出白话文的原因，相反展示出一堆日志异常堆栈，搞的平台排障工具只能自己使用，平台用户只有开发者本人。 总结 基础架构在很多公司是一个成本中心，公司投入的人力应该放在收益产出高的地方，在当下是帮助业务快速完成需求，还是建平台造轮子，需要结合实际做好取舍，集中力量解决问题，既要又要不可取。 最后最最重要的，基础架构需要具备一个好的产品能力，功能不是想一出是一出，它在你的场景下应该是长期可靠准确的设计。