一次运维失误触发我管理维度的思考（浅）

背景：

我们的应用服务架构设计已经支持不停机发版了， 但是某次上线的时候，由于运维失误，误更改了一个错误的 eureka 配置（我们当前生产的配置是运维管理的），导致了服务启动的时候从配置中心拉到了一个错误的 eureka  地址，结果就是连接不上： org.apache.http.conn.ConnectTimeoutException: Connect to [eureka-ip:eureka-port] timed out

原本我们的容器架构是支持健康检测失败自动回滚的， 巧就巧在这个问题应用服务只是连接不上 eureka， 但是它本身是健康的，所以k8s 未回滚。这个过程触发了我以下几点思考：

关键因素：

人的失误如何避免？

如何优化应用架构来换取服务健壮性？

多点风险因素并发导致风险概论提升，如何分散风险？

发版的时间节点是否应该优化？

可参考的优化思路及逆思考：

》人的失误总会存在的， 就象机器会宕机一样正常。可以放慢节奏，加强运维层面的规范执行例如：更改重要的基础配置的时候，两人或以上一起操作相互提醒。关注 CI/CD 的生命周期（打包-上传-启动），打包发版的时候加强日志的观察，在确认当前基点启动正常后再进行后续的发版工作，以尽可能减小影响。

》应用架构优化：管理 eureka 的连接超时异常，升级它的异常处理策略为 ：应用启动的时候连接不上就不启动服务，做失败处理（预期触发 k8s 的回滚以保证服务可用），或者光棍点把基础架构的建设都交给云原生——注意了未来中小型企业应用架构一定是云原生的要优于自管理、半管理的应用架构的。

》风险的问题，只能靠经验做风险预估，要分散管理风险也是依赖人的经验，方法论可以参考项目管理方法论，只是方法论本身还是基于经验的基础上得来的，且不可照搬照套，总结起来还是要靠人，引入风险管理工具等（最简单的就是文档，复杂的如直方图、因果分析图、帕累托图等）。

》对于发版时间节点的风险管控这点，但是本身服务就是无状态的，如果通过控制发版时间来限制的话，那是历史的倒退）。