标签：
05 MAY 2015 on 行业新闻
DevOps 这个词表明，开发和运维需要通力合作。然而在现实生活中，双方都会有不同的工作职责，同时看待问题的视角也不尽相同。大多数情况下，都是运维一方得到不公正待遇。为了让开发人员能更好地理解运维同学，而且能帮忙解决一些问题，本文分享了一些经验和看法。 
一般而言，开发人员通过产品功能来衡量工作成果，而系统管理员和运维团队则由稳定性指标来进行考量，后者往往反对这些新技术。开发同学使用这些新技术可以帮他们更快搞定某项功能开发，也许是一种新编程语言 Scala，它具有良好的伸缩性，同时也能更好地支持各种组件；或者他们更喜欢使用流行的数据库，比如 MongoDB，这种非关系型数据库能帮助开发人员更快、更灵活地更新代码。
虽然这些新技术可能会给开发同学带来诸多好处。但不可否认，这些新技术同时也可能会给运维同学带来很多困难。因为一个标准公司产品可能由数十个，数百个，甚至数千个技术栈构成，它们可能基于各种不同技术来进行开发。然而对于开发者来说，他们只需要专注于某一项技术（或者少数几个）。而大多数情况下，每个运维可能需要在同一时间里对多个甚至几十个应用进行监控。如果缺乏专业级监控软件比如 OneAPM ，就很难进行管理。
对于开发人员来说，他们只需要精通某项技术就可以做出一款伟大的产品。但是对拥有多产品线的企业而言，就可能带来扩展性限制或者安全性问题。运维同学就需要不断学习新技能，从而避免被各种运行 Bug 所难倒。如果某应用最初的开发人员又不幸离开了团队，估计运维同学就疯了。当然还有一些情况，比如很多开发同学都喜欢使用一些开源产品，但其兼容性往往都很差，这也给运维同学带来很多困扰。
开发人员可以提供哪些帮助？
在开发或者更新产品时，开发同学应该提前咨询一下运维同学，现在哪些技术最常用，而且还要考虑，在未来短期时间内，即使面临复杂的生产环境也能够顺利完成开发工作，运维同学则需要给出“慎重”的回答。这里有个好建议，就是尽可能坚持使用一些标准化组件。
开发同学相对来讲很幸运，因为他们通常可以不用处理遗留代码问题。运维则不然，很多企业的数据中心就像一个「科技博物馆」。甚至一些几乎用不到的老应用，运维仍需保障其正常运行，因为说不定它跟某个关键应用还有某种“藕断丝连”的关系。
开发人员可以提供哪些帮助？
其实，这个问题从本质上来看就是第一个问题，因为随着时间流逝，很多企业已经逐渐失去对技术层面的管控能力。而解决方案几乎一样：保持技术栈简单化和标准化，并考虑到未来需要哪些成员来进行维护。
很多开发同学经常说类似「我们在开发环境上跑的很好啊」这种话，然后把问题直接推给运维同学。遇到这种情况，一般是由于开发人员把代码嵌入到生产环境之前并没有做好测试工作。「我总不能老测试代码吧？我们已经在开发过程中完成了」，开发同学摆出这种态度，就意味着所有工作都抛向了运维。如果关系搞得很僵硬，开发同学甚至还会进行更频繁的部署，这无疑会让事情变得更糟。
那么开发人员可以提供哪些帮助？
其实，传统交付源码或者软件包最大问题就在于，软件运行期间所依赖的环境无法控制，不能标准化，IT 人员常常需要耗费很多精力来解决因为“环境”而导致软件运行出现的各种问题。开发人员可以了解一下 Docker 技术，这是一个轻量级的容器管理引擎，它可以将软件与其依赖的环境打包在一起，以镜像方式进行交付，这样就可以让软件运行在标准环境里，这也非常符合云计算的发展要求。当然开发人员也可以邀请运维同学参与到开发会议中，确保日志记录和监控等事情能够被妥善解决，这样基本上可以搞定这件事。
当然，除了 Docker 技术之外，现在市场上也提供了一些专业工具，比如运维可以将Application Insight 探针部署在开发环境「Development」、测试环境以及生产环境「Production」上，然后依次查看系统业务在不同环境下的性能表现情况。例如某个新功能上线时，在开发环境中没有错误，但在预演环境「Staging」中就可能会出现错误，运维同学就可以在 Application Insight 管理控制台上快速地查看各种错误信息，然后迅速对问题进行定位，分分钟就可以解决。
一般而言，公司管理者往往对技术了解不多。但是，无论是网站访问缓慢，还是系统出现各种错误，不管是因为谁，公司老大们都是找运维同学解决。从一定意义上讲，运维同学有责任去解决这些问题，但是不排除很多情况下是因为开发同学某段代码出现了问题，所以运维同学难免会抓狂。不仅要承担别人犯下的错误，还要拼死拼活地去解决可能非自身原因造成的问题。因为没有专业工具，运维很难快速定位问题所在，所以他们常常「有苦难言」。
那么开发人员可以提供哪些帮助？
开发同学要学会使用「暂停」 模式，尝试把代码交付时间向后暂缓一下。这样可以保证在出现问题之前，及时向开发同学伸出援助之手。通常而言，开发人员拥有更专业的经验和技术来修复各种问题。
其实，应用性能管理第一品牌 OneAPM 在这点体现最为明显，因为其核心价值就是希望帮助 IT 运维人员进行故障预警和定位，帮助减少业务系统维护工作量。同时能够能够实现从代码类、方法到数据库语句级别快速性能诊断。除了能让运维同学少背黑锅，还能帮助开发同学准确定位到问题代码段。从此，开发和运维同学也能在一起愉快地玩耍。
标签：
原文地址：http://www.cnblogs.com/qijiayi/p/4650540.html
