警惕从开发转变为运维
在这有限的三年工作中，我们尝试着从传统的开发|运维分离的体系转换为 Devops 的体系，收益很多：有且不限于
- 如何编写更易于部署的代码
- 了解K8S这样的运行支撑层的工作原理
- 促进团队的产能
但是在这过程之中我们也发现了很糟糕之处，今天就这些糟糕的情况讲一讲。
作为 Ops 的 Dev
大概没有比现在做开发更糟糕的事情了，开发者的心情大致上是这么波动的
好爽，这么可以玩的 -> 好烦，为什么做这么多 -> 老子再也不碰了
阶段1： 看上去美好的初次接触
糟糕的交付速度，老旧的运维技术，大概就是开发者对于运维的刻板印象，因此在 Devops 的初期阶段，开发者托管了这一切时候，世界真是美好，我们上了最新的 CICD 工具，我们用上了最酷炫的 Dashboard，我们还有最潮的在线 Profiler，新世界正在冉冉升起。
阶段2： 糟心的运维阶段
当迈过了内部的测试阶段，开始了正式的运维阶段，Dev 开始明白起来所谓的 自愈平台 HA 都不是完全的自动化，经常需要人员的介入，也就是传统运维经常做的事情，一般这个时候我们不得不一边进行运维，一边进行新业务的开发，如果拖着重重的行李。
正如在 What is shitty about DevOps? 中吐槽的一样
What I don’t love:
I’m on a dev team as the only ops guy: 我变成开发团队内的唯一的运维BOY
Management layout is so awkward. I report to a dev guy, take orders from an infrastructure guy： 管理模式如此的糟糕，我向一个开发主管索取运维资源
lots of hours： 失去了大量的时间
Some days I just want to drink： 有些日子我只想灌醉自己
更多的例子可以阅读 (参考2: #What is shitty about DevOps?)
阶段3： 痛苦的挣扎
此时的研发新的任务已经下放，在一边开发新功能，一边对已有功能进行维护，研发任务变成了运维的消遣。
作为 Dev 的 Ops
这倒是一个蛮不错的趋势，对于一些比较新潮的运维工程师来说，Shell 早就不能满足他们对于运维工具/语言的需求了，在早期已经使用 Python 来替代 Bash 来进行运维脚本的开发。直到 Cloud Native 时期，出现的 Go 就比Python更适合作为运维的工具，因此在此时期，我们也诞生了比如 Google SRE 这样的新型职位。
国内的 Devops 现状
不可置否的说，国内的 DevOps 现状和 DevOps 初衷是相悖的。DevOps的初衷是打破团队的隔阂，提高流程速度，而在国内这一切都被减本增效所掩盖，DevOps只是一个披着技术实则是管理手段。DevOps 工程师是一个人打两份工而拿1.5份工资的可怜角色。
在百度中搜索 devops 在可怜的前几页都发现不了任何关于 DevOps 的缺点，世间难道会有如此优秀的理论吗？真是值得怀疑。
总而言之，我也更赞成 Devops 是一种文化而绝非是工作的定义，Devops 的目标是将原本的 研发/运维/运营 体系打通换成一个环路，而这中并非只有一种角色，我们更应该让团队进行良好的融合，而绝非让某一类角色替代某一类。