再聊DevOps
DevOps 是如今科技类企业产品研发生命周期的一个事实标杆，它所涉及到的技术标准的面也比较广。分布式实验室特约记者张炯采访了云原生与 DevOps 领域的专家、DevStream PMC Member、思码逸 DevOps 专家胡涛，就企业在 DevOps 的推进与演变过程中可能遇到的一些现实问题做了交流。
张炯：如何看待企业 DevOps 平台本身的 SLA 要求，它们应该被设计在多高的可用性是比较合理的？
胡涛：DevOps 平台一般服务于企业内部，而且用户并不是时时刻刻都需要上平台操作，也不是在需要使用 DevOps 平台时，如果遇到平台不可用，就被阻塞工作。比如开发人员提交了代码需要 DevOps 平台执行一些 CICD 流水线，此时如果平台不可以，开发人员也可以先去继续写其他代码，这里的时间敏感性并不强。
当然，当我们遇到 DevOps 平台不可用时，等待 1 个小时是可接受的，但是半天甚至一天就很可能会对正常的交付进度产生较大的影响。所以我认为每个月的不可用时间如果不超过 1 小时，都还是可以接受的。1 小时的不可用时间对应的 SLA 也就是 3 个 9 左右。
张炯：如何看待企业 DevOps 标准化，企业在引入 DevOps 标准时有哪些要点需要被提前关注？
胡涛：我认为大多数场景下我们是做不到“One size fits all”的，也就是“标准化”可以解决很多问题，但是同时会暴露很多新问题。可能大家都知道“行业标准”的出现需要卡在恰到好处的时间，如果太早，会限制技术的创新发展；如果太晚，技术已经野蛮生长，走向了很多不同的分支，难以再落地标准。
DevOps 也一样，如果我们考虑 DevOps 里面的流程与工具的标准化问题，制定标准的那个人，或者是那些人，是否代表了企业 DevOps 能力最高水平？他们的标准是否会限制企业 DevOps 发展？
就像一站式 DevOps 平台，我们往往看到它解决了多数工程师上手 DevOps 工具的问题，一个 Dashboard，一次登录，完成需求管理、CICD 等等相关工作，但是我们也往往会忽视它的“天花板”效应。
这个平台就像一个“天花板”，限制了团队在 DevOps 上的持续创新能力，让大家在只需要专注于业务的同时，只能专注于业务。就像你的团队突然来了一个“满脑子鬼点子”的少年，他觉得 GitOps 更高效，想在团队内推行 DevOps。这时候你不得不告诉他：我们公司有自研的 DevOps 平台，我们有 DevOps 标准，有规则，我们必须用这一套流程，你不要创新，我们不欢迎创新……
张炯：DevOps 是一个保持不变的理念还是不断变化的？它有没有下一代或终极形态？可能会是怎样的？
胡涛：首先可以肯定的是 DevOps 不是一个亘古不变的理念。我在前不久写过一篇博客《什么是 DevOps？看着一篇就够了！》大家如果感兴趣可以打开这个链接 https://www.danielhu.cn/what-is-devops/ 阅读。在这篇文章里我给过一个总结：
DevOps 是一种文化理念、工具与实践的结合，目的是更快更可靠地向用户持续交付价值。其中最重要的是文化，文化要求 Dev 和 Ops 团队责任共担，目标一致，也要求整个团队持续学习，抱着成长的心态，Continuously Everything。其次 DevOps 离不开高效的工具集，工具是自动化的基础。最后我们要在各个环节追求最佳实践，不管是工具的使用，还是团队的协作模式，沟通方法上面。
可以看到，我认为 DevOps 里最重要的是文化，而文化里最重要的是持续学习，持续成长，持续一切，永不止步。所以我不认为 DevOps 会一成不变，或者存在某种终极形态。
张炯：不同规模的企业在 DevOps 建设的过程中，面对多种的研发技术栈，如何去看待整合开源的 DevOps 项目，或自研 DevOps 工具平台，或商业的、公有云的 DevOps 平台的选择与规划，比如 CICD 等，应该从哪些角度去考量它们？
胡涛：今年5月份的一次 meetup 分享中，我聊过一站式 DevOps、自研 DevOps 平台和开源 DevOps 工具链等的选择问题，大家感兴趣可以看一下：https://www.danielhu.cn/speech-devops-202205/
简而言之，一站式 DevOps 平台肯定上手更容易，它的出现也必然是因为能够解决相当比例的用户所遇到的切实的问题的。比如很多研发团队希望自己能够简简单单专注自己的业务本身，不希望，或者也没有兴趣在 DevOps 上花精力，这时候为一站式 DevOps 解决方案付费是理所当然的。
另外有些团队可能规模比较大，面临的问题也相对负责，或者说“不常规”。比如他们公司要求所有数据放在自己的数据中心，也就是首先不能采购云服务。其次可能在 DevOps 流程中间掺杂了一些审批流程，而这类的流程非常“定制化”，导致在市面上买不到一个“开箱即用”的 DevOps 平台。这时候如果这个团队又人力财力都充足，那就抽一波人，走自研道路，合情合理。
当然，还有一个选择就是开源方案。大多数团队都会选择用开源软件解决 DevOps 相关问题，毕竟开源很直观的好处就是：开放、免费、灵活。假如你的技术团队规模不大，这时候简简单单的“禅道 + GitLab/GitHub + Jenkins + Harbor”就能解决问题了，免费，而且部署维护也不复杂。甚至现在通过 DevStream 之类的工具可以实现接近于一键部署这样一条 DevOps 工具链了。
开源方案还有一个好处就是足够灵活，意味着你的公司有 3 个研发团队时，甚至他们可以自己分别选择适合自己的工具，实现效率最大化。同时在某个工具用着不爽的时候，也可以随时决定替换成新的工具。
综上，如何选择适合自己的 DevOps 解决方案，主要还是取决于自己的企业现状、人力、财力、观念等等。
张炯：对于中、大型企业，是建设统一的 DevOps 平台更好，还是允许几套 DevOps 平台并行更好？
胡涛：前面其实已经谈过一站式 DevOps 平台和开源 DevOps 工具链的问题了。当然，如果说自研的 DevOps 平台是一套还是多套好的话，我认为是一套好。不过这里有个前提，我认为 DevOps 的本质是持续演进，开源的方案更加灵活，所以我认为给每个团队保留选择自己喜欢的工具的权力是很重要的。
如果说不考虑开源方案的情况下，已经决定企业自己建设 DevOps 平台了，那么这时候建设多套所带来的重复资源投入等问题是很明显的。既然决定自研，就应该把相关资源汇集，组建一个足够能打的 DevOps 研发团队，建设一套尽量符合企业现状的实用、好用的 DevOps 平台。
可能多个平台的假设是基于企业内或许需要不同的流程来适配不同的场景，但其实一个平台内也完全可以支持多种不同类型的流水线，就像 Jenkins 里可以灵活配置 Pipeline 一样，而不是每一种 Pipeline 对应一个工具。所以既然是内部建设，那就集中资源建设一套好用的 DevOps 平台。
张炯：是否需要考虑由于 DevOps 平台的异常风险，导致整个 DevOps 平台瘫痪甚至危及线上的生产环境，可以从哪些角度去控制风险？
胡涛：风险肯定是需要考虑的，可用性问题其实在前面 SLA 相关问题中我们已经聊过了。我们在通过 CICD 实现快速交付应用，其实同时也保证了一个线上应用出问题后，重新部署或者回滚是比较快的。
其实 DevOps 平台本身也是一个应用，或者说是一组应用，这些应用本身也应该做到可以快速交付。比如如果我们用云原生的方式来部署整个 DevOps 平台，那么这时候哪怕重新部署这个平台，耗时也不会太久。至于 DevOps 平台瘫痪是否会影响线上环境，我觉得影响不大。DevOps 不可用只是让线上应用的更新迭代受阻，而不会影响其可用性，所以也谈不上什么危及。而 DevOps 平台本身如果可以在较短时间内恢复，基本线上环境是不感知这个变化的。
张炯：如何看待很多公司要求所有技术部门都有研发能力？
胡涛：我觉得合理。如果这里的技术部门指的是软件相关技术，那么无非就是开发、测试、运维、安全等等团队，这些团队没有一个可以有理由说“我们可以一行代码都不写”。我们简单想几个场景就能理解了：“自动化测试”、“安全扫描脚本”、“运维脚本”、……
这些团队/部门的很多工作都可以通过写代码来大幅提高效率和质量，反之完全不写代码就做不好相关的工作。因此我觉得这是一个理所当然的很基础的要求。
张炯：身为 DevOps 的领导是否需要掌握所有技术细节，还是更多的放权于人？
胡涛：如果是很小的团队，或许领导没得选择，必须掌握所有细节。如果是很大的团队，领导也没得选择，无法掌握所有细节。我们以一般情况来考虑这个问题，如何做好一个技术团队的领导？我认为领导首先要能够发挥整个团队的主观能动性，激励所有人，让大家都能够朝着整个团队的目标努力；而不是领导决定一切，其他人只负责执行。
一个技术团队的领导往往也是整个团队技术实力最强的，但是我相信他能做的工作只能占到整个团队的一小半，所有事情亲力亲为，所有决策都要抓在手里是不现实的。一个有活力的团队需要彼此多一些信任，领导只需要把握团队方向，为团队日常工作扫清障碍，让整个团队高效运转就行。
嘉宾介绍：
胡涛，思码逸 DevOps 专家，CNCF Sandbox 项目 DevStream PMC 成员，布道师，核心开发者；熟悉云平台、云原生生态技术栈，曾深度参与云平台从 0 到 1 建设，主导云研发团队 DevOps 流程制定与工具链开发工作等；著有《Kubernetes Operator 开发进阶》一书（将在今年9月份出版）；另外是公众号“胡说云原生” owner。
特约记者：
张炯，曾任职于携程数据库技术部，后通过 CKA、CKS 认证，从事云原生、DevOps 相关工作，现就职于蔚来汽车，从事 SRE 工作。
推荐阅读：
现在Kubernetes已经成了容器编排事实上的标准，会Kubernetes现在已经成了很多公司招聘后台工程师与架构师的基本要求。为了满足在职人员短时间内提升Kubernetes技能的要求，我们特别组织了本次Kubernetes线下培训。3天封闭式培训，15人小班授课，考不过免费复训，10月21日在上海开课，扫描下方二维码咨询详情。