问大家一个关于运维职责的问题

[LedChang]

中型企业，我们公司服务基本上都是 java war 包的形式提供出去，运维基本不改配置文件，要求开发提供好，各种环境的配置。他们部署上线要能直接部署。原来配置在包里，如果配置有问题，他们直接要打回重新出包，而不是改一下配置。这样合理么？

[notolddriver]

我是运维同学，而且现在工作内容部分也是 配合开发人员部署线上环境。公司也有用 Jenkins 所以来说说：
首先，请不要讨论我司当前部署过程的低效率性与低技术含量等[已经在修改了，目标是完全自动化流程。楼上有人讲到“配置中心”等等这种]。

题主公司开发环境我不清楚，但我司的开发人员是接触不到 生产服务器的环境。项目都是在自己本地测试通过，然后传到 SVN 。运维通过 Jenkins 编译出包，删除包内的配置文件，生产环境项目做备份，删除生产环境非配置文件[config 文件夹]，部署新版到生产环境，通知开发人员与测试人员。
1.若生产环境的配置文件稳定不变，那么好，我把其余的文件更新上去便可。
2.生成环境的配置文件需修改，那么需要与开发沟通，看在生产环境上如何配置修改。

上面是最基础的两种情况，还有遇到的一种是：一些生产环境的旧配置文件虽然不需要修改，但它的存在会影响到服务，你一定要删除掉。

作为运维，大部分情况下你不清楚项目中各类配置文件的作用。而作为开发，你虽然清楚配置文件各种参数的意义，但你不清楚生产环境是如何的。所以这点决定了，传统的项目部署工作是需要开发人员与运维一起沟通进行的，一起沟通进行的，一起沟通进行的。若都各顾着各，是做不好的。

若要各自独立进行，要么这种类型： @holyzhou 提到的“开发提供详细的文档”[感觉这种显然没有面对面沟通效率高]，运维去啃；要么技术上做到彻底消除这层问题。

开发人员若不能接触或者不清楚生产环境的情况下，让他们出可以保障直接运行在生产环境的项目包，显然是有点扯淡的；若生产环境或者说生产环境的完全模拟是对开发人员完全开放的，那你作为开发人员就要保障做到项目的正确配置。

最后：一定要多沟通，从根本上解决问题。明确自己的责任，做好自己的工作内容。

本来是下午要发上来的，但不知道为什么网站那段时间不太稳定，访问超时+502 错误。。。

[notolddriver]

若不在技术上完全自动化这些不适合人脑的工作，写错 IP 地址、写错端口、忘记修改某个参数什么的 太正常了。。

[salmon5]

流程问题。没有人制定流程。

[realpg]

@aibangjuxin
233333
我就不给你说我们曾经有个 35 岁的 JAVA 开发打报告给办公室：申请给公司安装 1Gbps 的宽带（ PS 2011 年）

因为他的项目出错，他本地无法复现，所以给服务器开了级别比较高的 debug log ，超大的日志预计下载时间好几天

[salmon5]

对于流程不规范的公司。特别是二愣子特别多的公司，
很多人是自保，所以看上去很古板或者不近人情。开了一个口子，平均一个运维怎么对付乱糟糟的几十个开发？！

[lslqtz]

@notolddriver 网站不稳定被人 c 了。

[mytsing520]

表示我的公司研发用了 docker 什么的根本不需要运维，我这个“运维工程师”只是用来打杂的= =

[yghack]

@mytsing520 docker 的模板和环境不是运维做的？

[mytsing520]

@yghack 用 daocloud+阿里云一次搞定

[salmon5]

@mytsing520 你有很多前提没讲。
“研发用了 docker ”，这只是单机版，和生产环境差距远了。
还有你们的开发有能力用 docker ，谁去推广（施压使用）的呢？

[SlipStupig]

@mytsing520 负责推 docker 到 server,可以自称自己是 docker 搬运工了

[yangmls]

吐槽一下楼上说要 docker 运维当打杂的同学

docker base image 谁来搞？不需要运维来弄？开发用的官方 image from 的系统五花八门， ubuntu centos 什么乱七八糟不统一敢在线上用？ container 没有编排怎么推上线，这系统不自己开发怎么用？当然你会说有 k8s 这玩意难道要开发帮你维护吗？ docker registry k8s 你要是不会 go 开发有个什么坑你都搞不定，还有开发的时候日志丢了就丢了，线上日志你不搞定持久化方案日志丢了谁赔？就这我都还没说到监控。

[lfzyx]

@notolddriver 你可以写个程序，设置好生产环境的配置文件参数，这样就不用每次部署都删除包内的配置文件，删除生产环境非配置文件了

[coagent]

我们是这样做的：
1. 服务器连接地址：所有程序连接 Redis, MySQL, RabbitMQ, Elasticsearch 这些时，服务器地址全部使用 hostname ，开发测试环境、预发布环境和生产环境使用不同的 hosts 文件，这样在配置文件里写 hostname 不写 IP 地址，解决了开发不需要知道最终连接的服务器 ip 地址是啥。
2. 用户名和密码：在配置文件里写类似 mysql_user_name 这样的固定名称， Jenkins 部署前使用 sed 替换掉，部署到不同环境时， Jenkins 里的脚本执行不同的替换。
3. 配置文件里增加、删除配置条目，在 Git 里有一份 settings_new.py 这样的文件，里面的环境配置信息如前面 1, 2 写， Jenkins 里的部署脚本会先备份当前配置文件 settings.py ，然后再 cp settings_new.py settings.py ，然后再第 2 点的替换。那个 settings_new.py 文件由开发人员维护，存在 Git 里，部署时拉 Git 就自动拉下来了。

[coagent]

补充下，第 1 点的 hosts 文件，在初始化环境时用 Ansible 配置到多台机器， Ansible 使用 j2 模板进行处理。

[defunct9]

很合理。
我们的测试环境是和真实环境一模一样的，测过，没问题就直接上线，不用改配置。

[dennyzhang]

很不喜欢配置文件写到 jar 包里。貌似 java 的童鞋们第一感觉都是这样做的。