运维意识

今天在走日常 Jira 例会的时候，提到一个事件，说的是一个产品其中的一个服务状态出了问题，日常的交易超额都不会触发邮件提醒交易员。我问了组里几个问题：

1. 为什么不会触发告警？

因为服务状态还是正常的，是某个服务内部的进程出问题了，但是可以在某页面打开这个服务的专有监控页面，查看内部所有的进程状态。

2. 谁会查看这个进程状态？

没人。

3. 这进程出错的时候是否会记录在日志里面。

不在对应的服务日志中，在一个特别的日志目录里面。

得到答案之后，哎。。。又是老问题，很多 10 多年的老程序员都有个毛病，就是缺乏：运维意识。在项目交付中我很常听见的一句话：别管了，上线后慢慢修。在创业团队来说，这种情况可能会更平凡，时间就是金钱，先占有市场，在看看调整，说不定还要推倒重来呢。如果情况好，还能招商引资做个整体重构，所有毛病都不需要担心了。

DevOps

但是，我们所在的银行业是传统行业，所有的项目都是通过了冗长的行内审批，所有产品都是经过了银监会汇报，银行的交付，质量是第一排位的，直到现在也没有业界的团队完美的落地了 DevOps，因为 DevOps 的其中一个目标就是让 bug 更快在生产环境发现，然后快速的修复，而银行是绝对不能接受这样拥抱风险的交付方式的。大多 Devops 在银行内部落地的时候，往往采取 UAT 的 DevOps，和以 MVP 的形式交付产品而已。

互联网

最近很多互联网背景的，带来了很多新的气息，快速上线，项目情况报喜不报忧，口头禅：出了问题就修嘛，有什么大不了的。但是真的出了问题，很少会思考问题的本质，就是将发现的问题修复，就心满意足的说“问题可以关闭了”。

运维思维

有人说一个专家程序员的价值不是在同样的时间能输出越多的代码，而是用越少越易懂的方式实现同一个功能。除此之外，其中还有一点，就是容易维护。这里的维护，不仅仅是代码的维护，还有系统支持，与业务支持。高手还是需要时间的沉淀，填了许许多多的“坑”，疼过了，总结出来的经验。书上只是告诉你应该怎样做，但是为什么要这样做，怎样场景需要这么做，在设计过程中考虑闭环整个功能或者系统的运维体系，是需要学习和积累的。