回归之一：运维是什么？

时隔九年没有再写博客，少了技术分享积累的快乐，今天开始决定再来分享工作点滴。第一篇运维是什么？
换工作以后一直在数据中心从事运维工作，从维护中间件开始。当初想法很简单，我要成为架构师就必须清楚应用的整个生命周期，而运维则是我当时一无所知的领域，没想到这几乎要成为我终身从事的职业。哲学命题里面首先要解决的是你存在的根本是什么，而运维存在的根本是什么呢？我个人理解，运维其实很简单，就是为了解决软硬件不足充当的消防员。
运维做的最多的工作就是加机器，重启进程，几乎每天都做，世界不毁灭循环不结束。而为了让机器变动，进程重启变得可控，让从事运维的人员可控，衍生了出了各种各样的制度规范，如ITIL，近几年流行的DEVOPS等等。规范标准解决的是多系统，多人员，多应用等规模化场景的问题，对于几千台，几十人的小规模应用建议就不要跟风费银子了，自己随便搞几个内部制度就能解决问题。
运维的所有工作都可以用变更来体现，不是在做变更就是在准备变更，或者在为上次变更擦屁股。变更是万恶之源，也是创新之筚路蓝缕，只有良好运用ITIL之精髓才能达到人天合一的和谐状态。变更，应急，问题，事前，事中，事后，排列组合就又出了各种万恶的检查审计机构，虽然不太招人待见，但确实是保障规模化数据中心正常运转的必备，东厂西厂在很长时间里还是有其存在的必要的。
数据中心应急工作中百分之八十甚至更多的时间就是重启进程，或者预备重启。重启治百病，没有重启解决不了的问题，如果有，再重启一次，再有把数据库重启，再有把操作系统一起重启，如果再不行，就要把万恶的开发拉来一起研究怎么重启。DEVOPS出现之前运维和开发就是天敌般的存在，相互指责相互埋怨，即使DEVOPS倡导非问责文化，但在考核导向不变的情况下，开发中心，测试中心，数据中心的组织机构模式下，推诿扯皮始终无法避免。从这个点上来看将DEVOPS作为公司战略来进行定位确实是必要的。
21世纪什么最贵？人才！运维的本质还是人。虽然离了谁地球照样转，离了谁组织依旧正常运转，但是，注意又是但是，优秀的人带来的是更大规模的机器运转，更少的宕机时间，更高效的应急，最小化的业务影响。优秀的人对业务推广，开发创新提供了更稳定的基石，而不是疲于救火，要安全甚于要效率。运维人才的培养和大多数行业领域的人才培养一样，基本是规模化的公司才能谈论，小公司挖一个就好了，没必要自己去栽培，也没有生长的土壤。
啰嗦不少，似乎运维还是有些模棱两可，不过盲人摸象，一千个莎士比亚一千个哈姆雷特，运维对于不同行业，不同公司，不同企业文化，不同企业战略都有不同的目标和运作模式，找到适合自己的就好。破鞋合脚，糟糠妻知冷暖，小工具解决大问题，不要盲目跟风，觉得不上AI就不是OPS，不谈中台不好意思说自己干运维的，用好SSH，用好crontab三五千台机器规模足够了。
最后用《道德经》里一句话总结一下：万物之始，大道至简，衍化至繁。希望近几年热火朝天的运维行业能多一些务实的公司，出一些踏实的产品，希望运维行业的人能多一些思考少一些浮躁，不跟风，不盲从，做好服务器扩容上线工作