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

[LedChang]

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

[kideny]

额，我最近就接收了一个 war 包，到现在公司服务器还没配好。
开发写的文档太差，部署太费劲了。

[LedChang]

@kideny 不说文档好不好，起码生产环境改配置的工作不应该在开发这边吧

[ruhua]

@LedChang 环境相关的配置文件有问题？具体啥问题

[clino]

不合理,话说"要求开发提供好，各种环境的配置。他们部署上线要能直接部署"这就不合理哈

[goodryb]

基础环境还是要运维来配置好的，如果是业务相关的配置，应该是开发在 包 里面提供，随版本一起发布，回滚也是如此。

[csdreamdong]

可以参考下， zookeeper

我们现在是， jenkins+docker+zookeeper

[LedChang]

@ruhua 写错域名或者端口之类的

[LedChang]

@csdreamdong 我们这儿网络环境都是隔离的，我是 QA ，测试环境用 jenkins 加一些 shell 脚本直接部署的，今天上线邮件中有个邮件版本忘记写了，运维直接说了句，不写版本不部署。 但是 1.随邮件的测试报告中已经写清版本了。 2.提供的 svn 库中最新的版本就是想要上线的版本，线上版本是倒数第二个。 3.配置文件也写版本了，难道会部署一个与配置文件不一致的包版本？ MDZZ

[holyzhou]

线上改配置效率低下,等配置文件很大的时候 牵扯到的配置项又有很多，可能有些还是新增的 这种情况下运维需要解包再跟你确定实际需要配置项确定无误再打包。 如果你愿意在我旁边慢慢指导我改完或者出一份详尽文档说明这次更新各个配置项的值，这种情况我是愿意自己来的，但是时间成本肯定还是存在的。又或者我们在上线前就沟通好配置应该填什么，等到上线的时候 直接扔下去就好了

[LedChang]

@holyzhou 是啊，我觉得需要配合是肯定的，但是强制交给原本对生产环境的 dev 起码是不成熟的，更别提一单配错端口之类的就踢回去重新打包是否更不妥？

[virusdefender]

你们需要的是 docker

[holyzhou]

@LedChang 流程都是这样做起来的，开始没人会爽。 至少 dev 清楚配置项所代表的代码里面的更深入些的含义 打包前可以先把配置跟运维那边再确认一下啊

[holyzhou]

@virusdefender 即使是 docker 配置也是 QA 那边改好的吧 ，运维只是 run 起来，保持交付物的一致性

[9hills]

配置随便改最后早晚会吃大亏。你们需要的是一个配置中心。

举个我们的实践，比如某个模块叫 fuck ， RD 的代码库以及发布的 release 程序包中，是一个 配置模板，类似于 jinja2 的那种，比如

#fuck_config.template
master.addr = {{master_addr}}
port = {{port}}


然后 OP 和 RD 共同维护另外一个代码库，叫 fuck_config ，里面存储一个线上环境的配置情况， eg ：

注：我司的机器都是在一个树上维护的


HostGroup: /online/www/xxx
port = 89
master_addr = xxxx.dev.com


HostGroup: /offline/www/xxxx
port = 1233
master_addr = xxxx.dev.com

这样部署的时候，会根据机器所属的 Group 的不同，适配不同的配置。


配置的修改， rd 和 op 均可以发起修改，和上线新版本的流程一样。

而且要求 RD 和 OP 均十分了解线上环境，而不是只有 OP 了解，这点尤其尤其重要！！！

[LedChang]

@holyzhou 互联网的 OP 都只是 run 起来？我没在特别大的互联网公司待过，原来在 ALU 的时候是，技术支持的同事负责 site 的部署，根据用户手册配置 site, RD 只是偶尔需要提供支持。 OP 不需要了解业务吗？

[holyzhou]

@LedChang 我指的是 docker 啊 .

[aibangjuxin]

作为一个运维同学，内容我还是看完了。顺带吐槽下，现在的开发同学。 30 多岁的开发同学了。想要从家里访问公司办公环境，竟然不知道 vpn 是什么，你给他解释下，竟然说。我们研发不需要知道这个概念。连出口 IP 地址都不晓得 还搞个毛开发哪 。要求从办公区网络直接访问 IDC 机房的数据库也就忍了。你能不告诉我，你开了个带管理界面的 Mysql 客户端，想要从线上直接倒出几个 G 的数据，然后还要找我 什么破数据库。卡的要死 。

[hl]

归根结底还是沟通最重要

[9999999999999999]

背锅啊

[snopy]

楼上的，你们用 tomcat 么？

[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 的童鞋们第一感觉都是这样做的。