程序员玩跨界，错在运维人员

在很多交流场合，我们或多或少能听到有小伙伴抱怨运维岗位工作没有得到老板或者公司同事的认可，这怪谁呢？私以为只能怪运维岗位的各位同行，为什么这么讲呢？我这个攒了很久的大招，今天终于可以释放出来了。

恰逢看到田逸老师写的博客《程序员，请不要抢系统管理员的饭碗》以及文章下面各位同仁的评论内容，很多小伙伴基本上是从一个系统管理员的角度出发说出了安全问题的原因是程序员不应该这么做而这么做了，那程序员应该怎么做，他们知道吗？从这篇博客中描述的安全问题出发，田逸老师作为系统管理人员排查问题的思路非常清晰，对于我们这些运维岗位的新人而言，是一次不错的学习机会。同时，这篇文章也让我想跟大家交流下在运维岗位的一些心得和想法（不一定正确，还有点羞于表达，想想还是写出来比较痛快），可能很多优秀的运维工程师和系统工程师会无意躺枪，请大家不要介意，无意针对任何人，只是有感而发。

不得不说，如果放在刚开始做运维工作的时候，我也会如田老师这样义愤填膺（可能描述不当，望田老师海涵）地跳出来指责程序员，“傻逼”程序员竟然还用root（不是root难道就可以直接出现在程序代码里面吗？），还在命令行中输入明文密码（运维人员不会这么做么？脚本里面也不行），还用lamp套件（运维工程师你们偷懒让程序员在服务器上部署lamp套件还怪程序员）。当然在不了解田老师公司具体的开发运维模式的情况下，我就不妄加评论文章所描述的安全问题事件中运维人员的失职之处了。

很多时候，运维狗和程序猿应该是好基友而不是情敌，在具体的工作中也应该是互相协作而不应该是互相指责的。每个岗位都有自己专注点和知识经验积累，当然也不可避免会有一些交集，尤其当公司业务规模不大，或者说某些岗位的人员没有体现出自己应有的价值，那么这种交集可能会很多了。运维和开发人员在整个业务系统建设过程中应该是互相协作，各有关注点，个人认为开发关注的是系统实现，运维关注的是系统运营。把一个系统该有的功能和该注意的点实现了，减少代码低级的bug，增强代码可读性和可重构性，这是程序员的职责所在。环境维护，代码部署，安全防范，容量管理，可用保障等是运维人员的职责所在。

当一个程序开始在生产环境运行后，主要的工作和权责就都在运维岗位上了，开发人员顶多协助处理问题而已。

业务在生产环境运行过程出现的任何问题，都是运维人员工作不到位造成的。可能有人会说，老板没有给运维人员这么大的权限（无法拒绝垃圾应用上线，那你至少应该告诉老板，让老板取舍）或者很多时候紧急上线，产品和开发人员在运维人员屁股后面的威逼利诱导致让一个有问题的业务应用跑在了生产环境（你让上的，风险肯定需要自己来承担，产品和开发人员才没时间处理线上故障啊）。无论什么借口，我始终坚持这是运维人员工作不到位，对自己岗位的权责认知不到位。先不说一些比较复杂，让运维人员无法拒绝的原因导致一个有问题的业务应用部署到生产环境，对于很多很低级的问题，运维人员都可能把责任推到程序员身上，除非你们公司就一个程序员而且还做着系统管理员的工作，否则还是自己认真检讨下：

1.没有运维人员的授权（或者说压根就没做权限管理）和支持，开发人员是如何把业务应用部署到生产环境服务器的：

目录777权限（rwx rwx rwx），这完全是在打开发人员的屁股，狂抽运维人员的脸。

一个应用程序不应该是由运维人员负责部署或者提供工具部署上线的吗？

生产环境维护，应用部署支持，这些都是需要运维人员处理的事情。

2.没有运维人员的默许，一些敏感信息能明文出现在生产环境的服务器上？

恶意的猜猜，这个程序员会不会也喜欢用root帐号连数据库呢？

关键配置文件可疑信息的扫描，这是运维人员必须要做的事情。

3.是否正确做到网络区域划分和内外网的隔离？

很多业务服务器是没必要直接访问外网，对于这些服务器阻断外网访问权限是非常必要的。如果你们公司只有一台服务器或者只有一个网段的话，当我什么都没说。

4.关于“root”这个问题，是否有相关明文规范，是否有相关指导说明（可能有人说了，我经常说了程序员不听话，还是老样子咋办。光说有毛用，你能跟每一个程序员都这么讲么，白纸黑字才是王道）。

我很确定，很多开发人员对于使用root有什么风险完全不清楚的，但是对于运维人员而言，这个风险是很清楚的，运维人员有没有明确告诉开发人员不能这么做，这么做有什么问题。完全臆测对方可能知道某些自己岗位知道的东西，出问题了还拿这些来埋怨对方的行为，完全实在耍流氓。

5.低级别或者第三方应用系统是否和主业务相关服务器做了很好的隔离。

每个岗位都有自己的关注点，以及相应的背景知识，如果能够做到充分的沟通交流，这样才不会产生不必要的信息不对称。

开发人员完全可以抱怨运维人员不能及时处理SSH相关漏洞问题。很多人看到这句话，运维人员第一反应是ssh有什么漏洞，我们经常登录系统的服务管你们程序员什么事，开发人员看到后会会心一笑，java框架strtus已经成为漏洞之王，防不胜防啊。你看对于一个简单的SSH三个字母，在不同的知识背景下，如果没有充分的沟通了解，很容易出现知识不对称造成的问题。我认为你应该知道什么，应该怎么做，事实上对方可能压根就不清楚你的想法。让开发人员知道生产环境有哪些为了保证业务高速稳定安全运行而存在的规矩，是运维人员义不容辞的责任。我们也经常碰到这种情况，线上异常应用抛出异常日志，运维人员看了半晌不知道错在哪里，有没有这种情况？开发人员一眼就能看出错误日志代表的是什么意思，而且有些二流的开发人员还以此为傲，这么简单的错误信息都看不多，怎么做IT民工的。我想说，程序员在应用中写的异常日志难道不是给运维人员看的么，搞的这么深奥，有毛意思？日志输出就是要错误等级分明，提示信息简单明了。

运维人员要明确自己的职责，做好生产环境的守护神，不要动不动就怪我们可爱的程序员，大家都不容易，我相信只要运维人员做好了自己的工作，更好地帮助程序员成长，老板和同事一定会认可你们的价值的。

别人能玩跨界，肯定是我们自己很多东西没做到位导致的。我相信大部分的程序员还是喜欢安心写代码的，运维这些杂事才懒得弄呢。不要给别人犯错的机会，不要给程序员折腾生产环境的机会，很多时候程序员能够玩跨界，要么这个公司没有运维岗位，要么完全源于运维人员偷懒，放开了相关系统权限，你能说不是这样吗？

程序员玩跨界，错在运维人员。

当然一个全能的程序员和一个全能的运维工程师都是不可多得的人才，开发人员要有运维思维和意识，运维人员要有开发思维和意识，对于很多像大众点评这种给每个程序员发一本《鸟哥的linux私房菜（基础学习篇）》和一本《hadoop权威指南》的公司点无数个赞，当然如果能给每个运维工程师发一些开发相关入门的书籍，那就更加赞得不能说了。

安全问题历来是一个大问题，不是说系统管理员就能比程序员解决安全问题的能力高多少，这是一个体系问题，需要设备，技术，制度以及人员，培训各方面的综合介入，当系统规模发展到一定程度的时候需要专注安全的人员（各种猥琐流）投入时间和精力来处理。只能说针对系统层面的安全问题，运维工程师或者说系统管理员可能会被开发人员有更深刻的认识罢了。

欢迎交流，同时希望更多运维工程师和开发工程师成为好基友或者好情侣，一起保证业务高速稳定安全发展。如果你认为自己在安全方面有更好的意识和经验，欢迎时刻在任何地方把你掌握的东西分享给大家。

啥？运维工作做的很专业很优秀的情况下，老板还不认可？欢迎联系我，我认识很多对运维工程师价值认可的老板。