以下是基于容器的DevOps对人员和知识储备的要求、落地后部门和流程的变化等相关内容，供感兴趣的同学参考。
DevOps除了利用docker快速进行开发测试上线外，如何向公司说明采用DevOps后的好处？
我司的环境是：开发环境、测试环境、定时停业务发布上线、上线功能性测试、上班时间生产、如出问题解决或回退（影响至少半天或1天）。
基于这样的环境，Devops除了利用docker快速进行开发测试上线外，如何向公司说明采用Devops后的好处？
@wykkx
devops是以业务为中心的，所有的动作(加快上线部署，版本管理，问题记录反馈，线上部署监控，发布迭代，故障及时响应，快速版本回滚)都是为了更好和更快的满足业务需求。本质上就是全方位的服务业务。
@caikai
DevOps是在传统敏捷的基础上，为了解决开发测试和运维脱节而出现的理念。我们在理论上就不赘述它能带来的好处了，网络上讨论的很多，总的来说，DevOps是一种工作模式，这种模式适合需求变化多、需要快速迭代、频繁上线的场景，比如微服务架构的应用就更提倡使用DevOps的模式。但推广DevOps并不容易，有很大的代价。
因此实际在做出是否采用DevOps时，理论的宣讲往往是不够的，需要用数据印证来说服决策层。那么就需要自愿的、或有领导安排的试点应用，我建议选择代码掌控在自己手里、发版也比较频繁的应用，除了建立自动化流水线，还需要把应用相关的开发、运维人员编成同一个团队，让他们真正为同一套KPI而工作，负责应用的全生命周期，通过运行一段时间后，用DevOps前后的发版频次、发版时间、发版成功率数据、沟通的效率来做比较，来决定DevOps你的部门的代价和收益。客观地说，也不是所有的情况下DevOps都能带来显著的好处，比如现在和未来你也不需要微服务架构，1个月才发一次版，那么你现有的流程和模式也许就已经运转得很好了。
@于昺蛟
首先DevOps就不只是加速流水线那么简单（那是敏捷开发的事，别搞混了）。DevOps运用了敏捷思想加速开发没错，但是本质上DevOps还是一个循环改进业务系统的过程，先在这里放张图：
这个就是DevOps的循环图。可以看到除了开发测试以外，DevOps更多的是持续的业务规划，快速迭代，持续监控，以及通过监控数据和用户反馈来优化系统。DevOps实际上是完全以业务为中心的方法。从初步构思、生产发布、客户反馈到基于反馈进行增强，DevOps不仅能最大限度提高产品或服务的交付速度，还可以帮助企业具备足够的敏捷性和精益性，快速应对客户需求、市场条件、竞争压力或法规要求等方面的变化，因此 DevOps 对于所有这类企业而言不可或缺。
容器在传统行业都还没有普及，就开始搞基于容器的devops是不是更难落地？
@wykkx
这个问题问的好。在容器还没有普及的前提下搞基于容器的devops难度确实大于传统基于虚拟机的devops，毕竟多了一层技术，这是事实。但是这个问题也要分角度去看，基于容器技术在带来学习成本的同时也带来了相应的优势。
对于开发而言，基于容器技术可以屏蔽底层操作系统和环境变量的差异，可以防止代码被人修改(尤其是在做依赖开发时)，尤其是如果要做微服务改造，容器又具有天然优势。带来的直接成本是需要学习dockerfile的写法。
对于测试而言基于镜像更有利于版本的管理。
对于运维而言好处是可以快速实现扩容和更容易的高可用保证，但同时也需要去学习容器的运维知识。
所以在我看来，如果公司容器和devops都还没有落地，可以选择一个支持容器的devops平台，然后用1-2个项目测试一下效果。记录下遇到的具体问题，然后具有针对性的调整策略(先熟悉容器或者先落地devops)
基于容器的DevOps需要哪些支撑(平台 和人员)？
@wykkx
平台方面，首先要有一个友好的容器管理平台，便于开发和运维人员使用，例如友好的dockerfile编写，友好的镜像制作功能，此平台可以基于swarm或者k8s改也可以采用商业化产品。其次要有一个支持镜像管理，利用镜像发布部署的的devops平台，另外该平台需要有ci/cd,监控告警，自动化运维能力。
@nuaays
首先基于devops的平台支撑了哪些业务、面向了哪些客户，
比如
–容器镜像管理及平台
主要牵扯到devops， 和几乎所有会用到的镜像的业务及人群；镜像分为 需要保护的基础镜像， 可清理的集成测试的镜像， 可能需要保护的release版本镜像等。当然，除了基础镜像外，其他镜像如果都可以通过代码某次提交能重新打包出相同镜像的，可以只保护基础镜像。
镜像管理平台，业界比如Harbor等镜像管理平台都是在官方Registry之上加入管理界面、权限、镜像同步的功能， 推荐不同关键使用不同 的镜像Registry做隔离，之间必要repo可以采取同步保持一致。
–构建打包及平台
Dockerfile的编写，基本的命令需要培训给开发人员/测试人员，每个repo都需要有一个Dockerfile。
镜像编译： devops负责准备ready， 实现方式宿主机打包或者docker in docker 、打包集群等可借助Jenkins及相关插件 检测代码仓库提交并自动触发编译打包。
–代码质量及平台
DevOps环节中的静态代码扫描和单元测试结果等由测试人员负责，开发人员也是关心的。
静态代码质量平台比如Sonarcube， 不同技术栈的单元测试结果评价方式可自己定义。
–服务部署及扩缩容、升降级
可以利用业界容器编排工具实现服务的部署，还需要考虑到集群的划分，是否需要SLB以便外网访问。
服务的升降级，牵扯到新旧版本应用上下线及相关配置、相关中间件系统的配置。
发布策略有蓝绿、灰度等，企业结合自己业务特点选择，不同策略牵扯到的人员也有略不同。
–服务日志和监控
DevOps需要将日志和监控系统分环境搭建好，并能提供友好的日志查询给开发测试使用。
执行监控指标已反馈业务人员，监控告警以多种方式及时给予devops及相关人员。
APM和链路跟踪也需要其他组件实现而且是侵入代码的，需要开发人员和DevOps合作。
后续如devops项目上线，由谁主导运维了？
运维部门是否适合做为主导devops项目推进，整体架构需要拆分的话，需要开发部门主导，运维部门除了提供基于平台外（当然可以建议多少资源呀？日志文件是否单独挂载san共享盘呀之类的等），似乎没有其它太多作用？后续如devops项目上线，由谁主导运维了？需要哪些人员，如何参与devops，职责如何划分？
@wykkx
第一，需要明确的是devops不单单是开发与运维还需要质量或者测试人员的参与，而且测试人员正是链接开发与运维的重要环节。
第二，开发与运维经纬分明确实不太符合devops的文化，devops文化讲究的是开发和运维各相互进一步，但是经纬分明也不阻碍devops落地。其实从发展的眼光来看，目前开发与运维经纬分明的现状也是会慢慢改变的。
第三，在经纬分明的前提下，通过一个例子来说明devops落地：
开发人员负责写代码，并生成镜像，将镜像推至镜像中心，然后利用平台进行单元测试。
测试(质量人员)利用devops平台进行集成测试并将问题反馈给开发，以及负责定制发布版本，并将发布计划告知运维人员。
运维人员拿到发布计划后结合具体情况安排发布或者建议质量调整发布时间。发布过程中根据自动化程度以及系统重要性知会开发排期支持。
运维的主导方还是原来的运维部门，只不过需要掌握devops平台的方方面面，并且对业务架构要有更多理解，这样才能够在devops推广中有更多话语权。
@nuaays
我觉得，如果是运维部门主导，首先运维部门要改变传统运维Ops观念，接纳拥抱DevOps理念，从资源、流程、协作、优化、安全等方面参与到和开发测试一起构建DevOps项目
@于昺蛟
DevOps是以业务为核心的交付流程，所以开发测试运维只是DevOps循环里的一半。真正的DevOps还要包括运营人员（运行时监控，数据分析），以及业务人员（持续需求分析，软件设计，优化）。至于职责划分上，DevOps相对模糊了职责划分，而是重视各种角色之间充分的协作和信任。
计划推进devops项目，在知识储备上，当前了解docker/k8s，需要什么样的知识或技能储备，才能更好的认识devops每一个环节呢？（或者说不被厂商忽悠呢？）
@wykkx
首先开发 测试运维都要对devops文化有一个基本统一的认识。开发同学要有良好的代码管理习惯或者说代码管理规范，并且能够使用ci平台进行持续单元测试。运维同学要熟悉python开发语言，有一个能够hold住的cicd平台，对监控的理解要至少提升到业务层面，并且具备批量处理的能力或者平台。如果使用容器技术，开发测试和运维还需要对容器技术有一定了解。
@于昺蛟
就这么讲吧，虽然DevOps一眼就会让人想到开发和运维，但事实上DevOps是一种文化，这种文化要involve组织中所有的利益相关方，包括业务、架构、设计、开发、测试、运维、安全……甚至合作伙伴和供应商。DevOps 文化的特征是在各种角色间实现高度协作、专注于业务而非部门目标、团队内部和团队之间互相信任，并高度重视通过体验进行学习。
所以如果真的某个人被指派成为这个大管家的话，那这个人除了必要的技术以外，更多的是要对业务和开发的整个流程都有深入的了解，知道整个交付管道的瓶颈在哪里，如何推动整个团队实现DevOps的最佳实践，以及在哪里可以推动业务创新。这么讲，推动DevOps最重要的工具还是人。