近期工作安排包括自动化测试、自动化运维、自动化运营和安全等一些工作。自己做产品、自己做设计、自己做开发、自己验收上线还是挺爽滴。
这其中工作简单的就是自动化运维。但我今天真正要讲的不是做了什么，或者用了什么技术，这些都不是核心问题。核心是面对一句话需求，要怎样去思考。
我拿到的需求就是 做全公司的自动化运维。那到底要做到哪些，做到什么程度呢。
总体规划
我的建议是优先找公司的标准，找不到再自己按照公司的阶段和情况把核心指标定下来。根据核心指标来拆解问题。
比如说公司跟客户承诺7*24小时不间断服务。那SLA服务等级肯定不能低于3个9。核心指标有了，三个9怎么做，四个9怎么做，网上一大堆。
针对我们公司的现状，我先出了一个总体规划。
阶段二和阶段四内容较多，单发图
阶段二
阶段四
大规划有了，咱们就一步一步做。咱们今天只讨论阶段一的过程。
运维提效
每个阶段也要先订核心指标。我定的核心指标是：可观测、可恢复、可应急。
指标定了，下一步就是从痛点解决问题。因为公司本身没有几个人，之前的运维流程也不完善，也没有设备和人力去界面化操作。之前测试环境发布、生产环境发布都需要上服务器上手工搞。需要随时随地手机上也可以方便的操作、观测、恢复和应急。
在电脑的管理端，用管理员账号登录后我们的操作界面长这样。
可以一键发布，同时也满足 一些应用不发布的个性化需求。恢复和应急方面支持回滚。可观测方面前端有实际发布内容的展示。发布过程中，发布按钮会展示发布状态。后端有发布节点目前状态的实时展示，还有心跳检查等状态检查。检查服务卡死会自动dump后重启。这是自动恢复。还有一键停服，一键重启等应急操作。但是这些都有额外的安全措施。安全的东西都不便于公开讲，否则就不安全了。
这个功能相比较其他公司用了各种框架，各种系统或者有专门团队来做的，确实是弱爆了。但是那些看起来花哨的功能都是有成本的。包括 资源成本，建设成本和使用人员的学习成本等。
而我做的这个从开发到上线用了两小时。其他人使用的时候学习成本就是跟我确认一下，平均每人2分钟。
AI时代下的变化
在传统的软件开发时代，设计了长远规划，那代码设计一开始就要考虑可扩展，要技术选型，可能要选框架来满足长远需求。而AI时代，系统重构变得简单，在这种不涉及核心业务的场景下可以先尽量简单的满足需求，反而更灵活更可以拥抱超变化。
