作者：顾伟
卷首语：2017年初，我们DevOps团队给自己定了个小目标，将自己的研发 过程以软文方式分享出来，于是就有了“无数春笋满林生”的画面，写什 么的都有：转型过程、项目管理、监控、运维、开发质量、测试管理、 安全……，不禁问自己，DevOps的目标场景是什么、该怎么做？
2015年刚开始规划DevOps产品时，很多人在议论这个产品的定 位。我们目标客户的IT现状是一穷二白的？还是相对比较成熟的？前者 会不会还不到DevOps的建设阶段？后者又怎么推动其做DevOps转型？ 一系列关于定位的问题背后，要求我们对整个软件工程进行重新审视：
1.过程来看，从瀑布到RUP、再到XP、敏捷、企业敏捷等，大家都 开始推崇大规模敏捷+小团队文化，由此可见，快速迭代、持续交付是 大势所趋；
2.工具来看，从早期的VS、Eclipse，到现在的TFS，RTC，工具本 身已经从开发运行平台，发展为软件生产线，合纵连横，是大中型企业 的发展必然；
3.组织来看，扁平化、去配管、零运营这些词被提及的越来越多， 究其本质，是从效率、协作、自动、甚至智能等角度思考，旨在大幅降 低管理与沟通成本，用机器替人；
DevOps作为软件工程发展的产物，要求企业在可控中不断度量、优化，将过程标准、将实践落地，形成可持续的生态建设。看看外面的不同声音，一般分三类：
1.概念的差异：有人说DevOps是Dev2Ops、也有人说是Ops2Dev，还 有像DevSecOps等新词的不断提及；
2.技术的差异：有人在讲，运用DevOps实现代码到线上部署的全自 动，也有讲SpringCloud+K8s下的DevOps最佳实践；
3.DevOps是好是坏：有观点是DevOps在扼杀开发者，然后又看到有 文章反驳，DevOps扼杀的不是开发者，而是开发生产力。
各类社区的观点层出不穷，有时在一些沙龙或闭门会议上还会激烈 争论，造成这个的原因，我们忽略了所有做产品的本质：业务目标是核 心、工具技术是手段，我们不该先谈论技术或东西的好坏，而是要清楚，你想通过DevOps解决什么问题。《DevOps转型陷阱与核心实践指 南》一文里以通俗的语言阐述了我们做DevOps的一些业务目标：
1.从需求出发，驱动任务执行。
2.任务和代码生产相结合，进行追溯。
3.以任务为单位进行持续集成。
4.以需求为单位进行持续交付。
5.以质量为纲，进行系统验收。
6.运维规范化。
7.随时随地的沟通。
8.持续监控，持续改进
简而概之：一条生产线，从业务需求到线上资产的全链路打通，持 续运营和优化。所以在后续的建设中，我们将项目过程切分成需求、设 计、开发、构建、测试、部署、运营阶段，梳理每个阶段的输入输出、 参与角色等，形成规范并通过工具不断提升自动化能力，旨在加速交付 速率的同时，提升交付质量。
再说到技术支撑，不积跬步，无以至千里，经历了两年多的研发和 灯塔客户实施，现在我们终于敢说，DevOps其实是没有标准产品的， 有的是你对企业IT过程管理与控制的理解、以及一系列工具技术栈的沉 淀。两年多的时间里，我们通过对诸多开源和商业技术选型，形成了一 些列能力封装：
1.项目管理，集成Jira，定义里程碑、路线图、各类过程看板，抽 象Jira模板，管理需求、冲刺、任务、bug等，形成最佳实践；
2.代码库，集成GitLab、GitHub、SVN等，打通账号与角色，形成 标准flow；
3.持续集成，集成Jenkins、Sonarqube、Gradle、Maven、 ESLint、JMeter等，打通构建、质量检查、部署、验证的开发流；
4.介质管理，集成Harbor、DockerRegistry、Nexus、Artifactory 等，提供统一介质上传与下载能力；
5.自动部署，集成Ansible、kubernetes、Swarm等，屏蔽异构基础 设施的差异，一体化的设计和部署；
6.流水线，集成BPS等，配合企业项目要求，动态编排流程，支撑 持续交付；
7.运维监控，集成Zabbix、Prometheus、ELK等，护航线上系统；
再说说我们DevOps产品的研发琐事，对很多产品经理来讲，每一 次版本研发，看着前序版本，都特别不是滋味，我们亦然。某些版本中 太强调项目管理的敏捷，却没有考虑企业版本火车式的敏捷；某些版本 太注重基础能力的建设，没有太考虑DevOps要千人千面；某些版本又 在技术集成上考虑的太复杂，甚至想完全覆盖某些框架能力。
说到底，没有理解好《人人都是产品经理》里说的，如何找到最有 价值的故事，优先交付。DevOps作为一个跨部门、跨角色使用的平 台，往往在需求阶段你听到的声音会特别多，作为产品经理，要深刻认 识到哪些是要做的、哪些是对手不易做的（给自己做的可忽略）、哪些 是自己易于做的，形成MVP式交付，就我们的痛苦过程来讲，需求变更 比很多产品比例要大。
合抱之木，生于毫末，如果你也在规划DevOps平台的建设和转 型，我们建议大规划、中平台、小起步。先将微服务、容器云这类容易 与DevOps混淆的概念拆出去（没有人说缺了它俩，DevOps就没法做），接着将DevOps化成四块：
1.狭义DevOps（就是你的第一个版本），解决标准规范的问题，落 地项目管理与CICD，横向打通部门交付物，纵向集成常用工具链，在质 量和安全前提下，提升交付能力；
2.自动化测试，很多人会有疑问，测试不是DevOps中很重要的一环 吗？是，但是随着各类技术的流行，即使独立建设自动化测试平台都会 很吃力，如果耦在一个版本里，很难短时间看到效果；
3.统一监控，包括体验、应用性能、系统、基础设施等，这个其实 并没有那么紧迫，生产线不标准，何谈“统一”监控；
4.智能运维，这个是一个理想，就目前来看，很难做到，开发与运 维不能很好衔接，就不要去想着去运维这件事情了；
说在最后，弄清楚你的DevOps业务目标，结合其他人遇到的问题 总结，提供的技术方案，小目标、快迭代、持续优化，相信DevOps转 型会变得很简单。