DEVOPS的一些想法

Google SRE教了我们很多方法论，比如怎么做设计一个分布式监控系统，软件过载了怎么处理，面对日常琐事怎么执行on-call轮值等等，这些都是Google在践行DEVOPS道路上总结出来的非常宝贵的经验，但是，有没有想过，我们为什么要做DEVOPS，为什么单纯的OPS就应该被淘汰？

从我毕业做运维开始，就一直听到devops，从不理解到理解再到想着怎么做一晃就是五年，这次正好看了Google SRE，对比之前所做的工作，说一下自己的理解。

我就是不想做DEV才做的OPS

其实从一开始，就是做OPS的，就像我大学里说的那样，不想写代码，就做运维了。最开始做SA，做PE的活，确实不需要太多的DEV，就是纯粹的OPS。那时候，还没有太多的自动化，发布代码需要通过自己的脚本批量的rsync到每台服务器上，最壮观的时候是发布时间窗口一打开，身边围着一群开发，让你帮着上线代码。

回头想一想？那时候完全走得通，或者不得不这么做而且还能做得下去是因为服务器太少的缘故，全站的服务器不过200台，web服务器也就50台上下，我人肉完全搞的定，甚至我能记住每台机器的IP地址。但是当时随着业务的增长也是感觉到必须要自动化了，于是有个自动化开发的团队，帮我的脚本功能做到web平台，再后来变成了开发自助，天了噜，完全没有我们什么事了。但是我还是在OPS，DEV有运维开发在做，我提需求就是了，我依然过得很快乐。

不得不DEV

记得后来专职做DBA后，第一件事就是写个全站的MySQL监控，因为基础监控用的zabbix，监控维度是物理主机，而我们MySQL的监控维度是单个实例，不能依赖zabbix，不得不去写一个监控程序，后来又写了redis的监控，redis的高可用组件，最后还得写一个web平台来把这些监控平台化。

用的人不开发，开发的人不用

对比之前的OPS，或者完全依赖运维开发有什么区别

1，想要什么功能，上午想到，下午就能加上去，完全自己把握

2，功能上午用的不爽，下午就能改爽，无需运维开发排期

3，了解了一些开发的思路，和开发撕逼更加得心应手

4，写代码的获得的成就感远大于一直做重复的OPS

那么，这些好处是支撑我们必须dev的理由吗？其实我觉得不是。

真正让我们运维走向DEV之路的是我们再也无法忍受了！大量重复的工作，面对开发各种琐碎的小事，OPS面临着7*24小时的不间断打扰，还有管理越来越多的服务器，越来越复杂的运维环境，我们没有那么多精力去保证自己负责的业务7*24的稳定，我们的KPI收、受到了严重的挑战。所以，我们需要CMDB来管理我们的服务器资产，需要监控系统让我们时刻知道我们的服务是否稳定，需要工单来收集研发的各种需求，更需要自动化的部署服务，处理日常工单，解放我们的双手，来做更多的DEV工作，让运维变成一个有产出的部门，而不仅仅是一个支持部门。

工具化、平台化、自动化、可视化

我们没法一上来DEV就很高大上，做一个非常完美的系统平台。可能，一开始仅仅就是写了一个帮我们处理重复工作的一个脚本，后来大家发现其实每个人都可以用到这个脚本，就改成了一个通用工具，工具越来越多，我们就把这些工具放到一个平台里，让更多的人能够自助的使用这些工具。这时候会发现，原来，早已经走在了DEV的道路上了。那么，总结起来DEVOPS的工作重心是工具化、平台化、自动化、可视化，围绕质量(稳定性)、效率、安全、成本展开的。