你所在的公司是如何实施DevOps的？

我是做DevOps这个领域的创业者，跟一些中小互联网和传统IT公司都有过这方面的一些探讨。

现在对实施DevOps有想法的公司，多半都是业务发展还不错，在研发和运维上都比较大的压力的公司，希望通过引入DevOps来提升公司IT部门的总体运作效率，来支撑业务的发展速度。

关于DevOps对效率的提升，Puppet出过一份调研报告，算是比较成体系的。

中文版的报告链接在此：

工欲善其事，必先利其器，现在大家在DevOps领域最关注的还是在工具层面。

下面是我跟这么多公司接触下来，大家使用比较多的工具：

1、监控工具

比较老牌的就是Zabbix,Nagios，用Zabbix的感觉是最多的。

国内的有小米开源的OpenFalcon。

这类监控工具一般是对服务器、服务（中间件，数据库）做一些常用指标的监控。

2、性能分析/APM工具

APM很多时候被认为是监控的一个细分领域。

但在现代复杂分布式系统架构下，APM工具往往更能准确、直接的帮助用户定位到性能瓶颈，比如哪一个URL访问慢、哪一个方法执行慢、哪一个SQL执行慢。

在以往要想拿到这些数据，往往得需要比较资深的架构师、DBA一起合作才能拿到这些数据，而定位瓶颈的效率往往还不太高。

现在通过APM工具能让普通技能的运维人员，也很高效的定位到这些深层的问题。

现在商用的APM工具不少，国外的有Newrelic，国内知名的就有听云、Oneapm、透视宝这些。

开源的也有Pinpoint（naver开源）、Zipkin（twitter开源）、CAT（大众点评开源）.

3、批量+自动化运维工具

这里就比较多了，知名的有Puppet、Ansible、Chef、Saltstack这些。

这些在网上的资料也比较多，找比较新版本的官方文档看就行了。

Puppet和chef是比较早期的工具，受众面也很大，不过这两个工具基于ruby实现，现在要找到熟悉ruby的人来做这块的二次开发可不容易。

而ansible和saltstack则相对新生代一些，目前用户基数增长很快，基于python实现，要找做二次开发的人也相对容易的多。

4、集中日志分析工具

在一个服务器比较多的环境下，如何集中的管理和分析、查询日志，已经变成一个比较强的需求了。

想象一下，如果发生了某个错误，你还得一台台机器去翻日志文件，是不是很蛋疼。

在这个需求驱动下，就诞生了一些集中日志分析工具。

在开源领域，比较知名的就是ELK这一套工具了，涵盖了日志采集、上报、搜索、展现这一类基本需求，现在比较多的上规模的企业都用这个，网上资料也大把。

核心实现机制都是通过一些日志采集代理（类似Filebeat）去爬日志文件，将最新的部分提交到采集服务端，后端再对接搜索引擎，能支持很快速、准确的搜索即可。

有一个国内不怎么知名的Sentry日志收集服务，比较轻量级，本身是Python做的，与各种语言的日志框架做了非常好的集成，可以很方便的集中收集异常日志，并分配给对应的开发人员。

它在github上有10000多个star了，这在DevOps相关的软件里，都是排名非常靠前的了。

git的地址：

5、持续集成/发布工具

我接触的人都是用Jenkins的，没有用其他的，可能跟我所在的技术圈子有关。

集成打包的过程其实一般都比较简单，配好版本库和打包脚本就行。

但发布的过程就比较复杂，有些是全量发布，但也有非常多的IT团队采用增量发布。

这个方面如果想用工具，还是得先分析清楚现有的发布流程，手工情况下怎么做，哪些能通过自动化工具来完成。

6、IaaS集成

最近两年的公有云推广比较迅速，很多新的服务器采购都被导入到云上去了。

现在主流的公有云都提供了比较完备的API，基于这些API也可以做一些针对基础资源的自动化操作，比如游戏行业的快速开服。

说到 DevOps，就不得不先说明 DevOps 到底是什么。
软件开发最高效的组织形式是“One Man Work”，只有一个人干活，写个小项目，从需求到开发，从测试到部署全部独立完成，非常高效。但随着业务的增长，项目开始逐渐变得庞大，变成团队，出现了分工，出现了产品经理、项目经理、开发、数据、测试、运维等等角色。这些角色间存在天然的工作目标上的矛盾。
举个例子，对于运维来说，稳定压倒一切，新 Feature 越少越好。而对于研发来说，却希望能开发更多的功能。这种矛盾会导致大量的资源和时间的浪费。就像两匹马拉一辆车，如果马头向着的方向不一致，肯定是没法全速前进的。

DevOps 的理念就是希望能打破这种屏障，让研发（Development）和运维（Operations）一体化，让团队从业务需求出发，向着同一个目标前进。
字面意思上说 DevOps 是指“开发运维一体化”，即通过工具辅助开发完成运维的部分工作，减少成本。但深入理解了 DevOps 之后，你会发现 DevOps 其实是一种软件研发管理的思想，方法论，他追求的是一种没有隔阂的理想的研发协作的状态，可能涉及到的角色有开发、测试、产品、项目管理、运维等等。所以我们认为，为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于 DevOps 的范畴。

比如 Google 提出的 5 个 DevOps 原则，这套原则中必须依赖于工具辅助的部分只有后两点，更多的则是对于开发组织形式的内省：

1. 精简组织架构；
2. 愿意承担一部分试错带来的损失；
3. 分阶段地一小步一小步地进行转型；
4. 最大化地利用工具和自动化流程；
5. 对所有的过程和结果进行记录和分析。

所以 DevOps 不是简单的开发软件化，而是企业的学习能力不断提升的结果，将企业改造成敏捷应对的学习型组织，运用新的工具，优化组织架构和流程，不断地进行自我革命和创新的方式。工具是辅助，而非基础。

这里分享三个 DevOps 转型成功案例：HP LaserJet 固件研发团队、美国移民局、Lloyds 银行技术团队——

但 DevOps 目前在国内的实践现状困难重重。根据南京大学 «DevOps 中国•2018 年度调研» 的调研报告，目前设有 DevOps 实践团队的公司中，科技和互联网行业占比接近 70%。其他行业的从业者对 DevOps 的认知还存在一定的不足。
这与我们的调研走访体验一致：大多数企业都愿意尝试运用 DevOps ，但是在实践 DevOps 中，普遍碰到了比较大的困难。详细可阅读下文——

不过 DevOps 终究是未来的趋势，是企业未来的长期诉求。
从大趋势上分析，未来所有企业都将是软件企业，制造软件、服务软件、构建于软件。比如全世界最大的出行公司 Uber，其实是一个软件公司，而非出租车公司。从企业自身诉求出发，中国的中大型企业已经逐步进入了创新驱动的阶段。无论是供给侧改革还是智能制造 2025 都要求企业修炼内功，提高效率促进创新。过去几年中在塑造前沿行业的 DevOps 理念将在 2019 年左右成为主流，成为企业能否在行业内脱颖而出的关键性因素。

如果对 DevOps 感兴趣，可以关注 CODING 的专栏 DevOps 实践指南 ，持续分享敏捷开发、DevOps、持续集成/部署等领域优秀实践，感兴趣的同学可以了解一下，欢迎交流分享。