"囫囵吞枣" 二、Devops浅谈

2022-02-21

囫囵吞枣 devops

0 0

软件流水线

1913 年，亨利·福特提出机械传送带来运输零件让工人进行组装，原先装配底盘所需的 12 小时 28 分的时间减少到 1 小时 33 分。流水线概念实际第一次应用在工厂，产品开始“标准化量产”。

工程实践相比于理论学说，在意的是可行性：技术能否落地、产品能否有市场、能否标准化量产。

软件生命周期(Software Life Cycle,SLC)，将从软件的诞生到最终交付，大致可以分为 6 个周期：问题定义及规划、需求分析、软件设计、程序编码、软件测试、运行维护。

通过 SLC 将软件的岗位初步分工为了产品、架构、开发、测试、运维等。SLC 解决了软件如何“标准化量产”，自此“软件”由原来的个人小作坊变成了工业化“流水线”。

为了将 SLC 理念贯彻到实际的软件生产中，有许多的模型被别提出，其中典型的就是 Winston Royce 提出的瀑布模型。这个模型有一个非常大的弊端：“完成上一个阶段任务后，才能进入下一个阶段”。在如今激烈竞争的互联网行业中，讲究的是“躬身入局, 顺势而为，以业务为导向，各部门端到端,、点对点协同作战，用小步快跑、快速迭代的复用打法在新赛道上深挖垂直领域，抢占行业生态位，形成行业壁垒”效率二字。风口有了，但是要把握风口，还得快速适应市场的需求。

敏捷开发 Agile

既然市场（用户）的需求的变化的快，那么在软件开发的前期不追求完美、高质量的设计，而是力求短周期内开发出产品的核心功能，在后续的生产中，不断迭代完善。因此 Martin Fowler 提出了“敏捷开发。在敏捷开发中原本的程序编码、测试环节被分成小节循环反复的执行，以求快速开发产品的同时保证产品的质量。

DevOps

解铃人与系铃人

在早期，软件的开发与运维是几乎没有交集的两个工作，而且开发和运维本身是一对矛盾体：开发不停增加新功能满足新需求；而运维则信奉着“稳定大于一切”。~~甚至两个团队之间 KPI 考核都是冲突的，这对团队管理而言是灾难性的~~。往往产品的正式交付，并不能一次性保证能平稳顺利走完整个产品流水线。
当软件上云后，分布式系统庞大复杂，很难再将分布式系统维护和分布式软件的设计实现分离出来，软件系统不再只是简单的“软件 + 操作系统”，还涉及云服务、网络资源、负载均衡、监控、CDN、防火墙、DNS 等等。编写软件的工作人员不能只关注软件业务，还要了解软件与系统的其余部分的关系，而运维人员也必须了解软件的工作原理。

DevOps，develop&operation，开发运维，初衷在于将两个团队组织到一起：协作、共享知识，在软件的整个生命周期中，运维人员在项目的开发期间就接入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定对应的运维方案。而开发人员在运维的初期参与到系统部署中，为部署提供优化的建议。

Devops 并没有明确的定义，Docker 的前生态系统开发总监 John willis 认为 DevOps 是：Culture、Automan、Measurement、Sharing；Cloud Bee 的 Brian Dawson 说 DevOps 是：人员与文化、流程与实践、工具与技术。

结合敏捷开发的循环理念，如此一来整个软件生命周期便周而复始，持续反复。

持续 continue

随 Devop 而来的是 CI-CD-CO，持续集成-持续部署-持续运维。

Integration，持续集成；频繁地将代码集成到主干，通过在应用开发阶段引入自动化 来频繁向客户交付应用的方法。持续集成强调开发人员提交了新代码之后，立刻自动的进行构建、（单元）测试。持续集成过程中很重视自动化测试验证结果，以便提早发现问题。
目的：产品快速迭代——代码越早推送（PUSH）出去，用户能越早用到，快就是商业价值。
Deploy，持续部署；通过自动化的手段将部署的操作过程进行简化，降低部署的复杂度，使得部署是一个随时可进行的快速活动。通过持续部署到测试环境、准生成环境中，可以使测试团队尽快开始测试，开发团队获得快速的反馈并响应。
Operation，持续运维；运维人员可以对业务大数据进行采集、清洗、分析、展示等，实现自动开合服，优化网络性能，预警系统故障等，不断提升业务体验，辅助运营决策。

也有 CI/CD 的说法，CI/CD 指的是持续集成、持续交付（Derlivery）（交付即敏捷模型中的部署-运维）。还有 CI-CT-CD 的说法，但是一般认为 CI 的集成包括了测试，因此没有采用这种说法。

除此外，还有 DevSecOps 这个说法，让安全团队也参与进来。

SRE

解决问题最好的方法就是解决提出问题的人

Google 的 VP Benjamin 在 2003 年加入谷歌时，当时 Boss 给他的任务是让他组建产品团队。但是在此之前他一直是只负责写代码的程序猿，他于是按照自己运维的理解和想法和组建和带领这个团队。团队中 50%-60% 的成员就是 Google 的软件工程师；其余 40%-50% 的成员他们本身符合 85%-99% Google 软件工程师的招聘标准，但他们具备一些软件工程师没有的技能（系统、网络、存储）。这成就了谷歌的 SRE（Site reliability engineering) 团队！

SRE 团队通常由系统工程师和软件开发人员组成。工程师的工作是使用软件解决问题。他们还必须轻松地与开发团队集成。其背后的想法是提高代码和自动化测试的质量。SRE 花在纯运维事务上的时间不应该超过 50%，SRE 至少要花 50% 的时间进行工程项目研发，以便能够研发出更好的自动化和服务优化手段来更好地服务整个业务。

SRE 是目前谷歌对 Devops 理念的最佳实践！~~说白了，SRE 就是既会研发和又懂运维的大佬，这样团队的 KPI 就不会像 DevOps 有明显的冲突了。~~

服务质量

但 SRE!=Devops，Devops 的侧重弥合开发团队和运维团队之间的“鸿沟”，而正如 SRE 的名称中的 reliability，SRE 更关注的是软件的服务质量。

SLA = Service Level Agreement = 服务质量协议，SLA 是 SLO+ 对目标用户的承诺
SLO = Service Level Objective = 服务质量目标， SLO 是 SLI 的目标范围
SLI = Services Level Indicator = 服务质量指标， SLI 是度量指标

这么理解：比如轮询时间（Query Per Second）、往返时延（Round Trip Time）等具体数值等等是 SLI；为 SLI 设置范围（99.9xxx%）是 SLO；当提供了 SLO 且为用户提供服务承若协议后则是 SLA。

通过 SLA/SLO/SLI，可以帮助团队保证运维质量的同时确定哪些要开发的新功能。

总结

为了保证高效稳定的流水线交付软件，为了协调开发、运维之间的关系，Devops 理念运营而生，CI-CD-CO 为软件的生命周期指明了循环方向。
什么是 Devops？如何落实 DevOps？这是技术，是职位，是团队，还是方法论？Devops 的四大关键词：Culture、Automan、Measurement、Sharing。谷歌招聘具有系统工程经验和软件开发经验的人组成 SRE 团队，但注重产品服务质量的 SRE 团队真的就是 Devops 理念的的唯一解吗？
基础平台革命（云）、团队组织革命（Devops），现在离云原生革命就差最后一块拼图了——容器化技术。