有点近的原因
说它离我有点近，是因为自从进入软件开发这个职业，DevOps就始终在围绕在我的身边。正式进入这个职业应该从10年的算起，那时刚毕业，进入一家以开发销售网络管理产品核心业务的公司。因为是开发网络管理产品，涉及到一些协议分析、包数据处理。那时采用的技术栈是C语言+html+javascript. 那时刚入行，一个字“学”，公司没有使用类似apache http 的web
服务器，web服务器都是自己写的。html的解析也是基于libxml进行开发与封装一些标准函数库。因为系统涉及到较多的模块，每次需要手动编译源文件。所以开始使用make + Makefile做为程序构建工具。然后把构建出来的程序，借助sftp手动上传到Linux服务器（那时用的是redhat 5）上. 然后接下来就是基于web 表单的手动测试，看日志，看控制台输出.... 虽说比较传统，但它已经有DevOps的影子了，开发与运维由我独立承担。
有点远的原因
说它离我有点远，是因为自从进入软件开发这个职业，技术变迁十分快，10年的时候在自己完全没听说过DevOps,更没听说过云计算与大数据。但是从12年到17年，这些感念火爆了。12年的时候，你说自己是做云计算的，人家会觉得你很牛逼。但是现在你说你做云计算的，人家只会说“哦，我们也在开发云平台，我们在使用容器了，我们开发都是基于DevOps了”。这是我感觉到的技术变化。当技术脱离了核心业务，技术只是说辞。所以我感觉DevOps离我有有点远了。
大与小的矛盾
在小公司里，开发团队常常也要负责运维，而大多数大中型公司会有独立的部门。每个部门都有独立向上汇报的途径。运维会有运维的领导，开发团队会有开发团队的领导。当每次在生产环境上进行部署时，这些团队及其领导都会极力证明问题不是他们部门的错误。很明显，这是两个部门关系紧张的潜在原因。每个部门都想将部署风险降到最低，但他们都有自己的手段。
本文分享自微信公众号 - 云服务圈（heidcloud）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。