【运维者说】程序员玩跨界，错在运维人员

   

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

   

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

  不得不说，若是放在刚开始作运维工做的时候，我也会如田老师这样义愤填膺（可能描述不当，望田老师海涵）地跳出来指责程序员，“×××”程序员居然还用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权威指南》的公司点无数个赞，固然若是能给每一个运维工程师发一些开发相关入门的书籍，那就更加赞得不能说了。

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

欢迎交流，同时但愿更多运维工程师和开发工程师成为好×××或者好情侣，一块儿保证业务高速稳定安全发展。若是你认为本身在安全方面有更好的意识和经验，欢迎时刻在任何地方把你掌握的东西分享给你们。

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

相关引用：

程序员，请不要抢系统管理员的饭碗：http://sery.blog.51cto.com/10037/1429418