DevOps

认识DevOps

DevOps: development 和 operations是一组过程、方法与系统的统称，用于促进软件开发部分、技术运营部门和质量保障部门的相互他沟通协作与整合。
核心价值：如何通过DevOps实现最终的价值交付和输出。
原生能力：通过工具辅助开发人员完成运维人员的部分工作，减少成本。
DevOps的流程是一个全局感念，贯穿需求交付、资源交付、软件交付、产品交付的整个过程，实现最终的价值交付。
流程的种类：
1 流程价值的流转
2 流程价值的跟踪
信息传输流程
需求交付流程
研发交付流程
项目管理流程
3 流程价值的复盘

为什么需要DevOps文化？
对于企业，文化具有统一思想和价值流向的作用。对于IT组织，DevOps文化的作用更为聚焦和纯粹，促使组织成员不断进行知识沉淀和过程管理并将结果反馈至组织，从而提升组织级的效能和质量。

文化特点：
1 具备全局的系统思维
2 关注业务需求是否契合IT组织文化
3 共担责任
4 勇于试错
5 善用数据，通过数据说话

DevOps 周期表

点击即可浏览

https://digital.ai/wp-content/uploads/2023/12/digital-ai-periodic-table-of-devsecops_dec23.pdf

源码管理：Git、Subversion、Bitbucket、GitHub、GitLab、Gerrit
数据库自动化：Delphix、Flyway、Redgate、Quest Toad
持续集成：Jenkins、GitLabCI、Travis CI、CircleCI、Gradle、Ant、Maven、Meister
测试自动化：Mocha
配置管理、Chef、RackHD、Salt、Ansible
部署管理：Rancher、Helm、Automic、CodeShip
容器管理：Docker、Docker Compose、Kubernetes、OpenVZ、Nomad、Tectonic
发布编排：Clarive、OpenMake、Spinnaker
云管理平台：AWS、Azure、Alibaba Cloud、GCP、Huawei Cloud、Tencent Cloud
智能运维管理：ELK、Zabbix、Rollbar、Fluentd
监控管理：Zabbix、YouTrack、Prometheus
安全管理：CyberArk、Snort、Burp Proxy、Charles
内部协作：Cisco Spark、Polarion、Morpheus

持续集成和测试

传统的DevOps中，3C是指Continuous Integration（持续集成）、Continuous Deployment（持续部署）、Continuous Delivery(持续交付)

后来逐渐演变为： Continuous Integration（持续集成）、Continuous Delivery(持续交付)，Continuous Operations(持续运营)

• 持续集成：持续进行编译、测试、检查和形成制品的过程。源码仓库发生改变时，需要持续触发构建动作。
  优点：
  更早的发现缺陷，从而处理缺陷，提升效率和质量
  及时的对持续集成过程中的数据进行采集和分析，最终形成反馈机制，推动交付团队进行优化。
  通过代码的持续增量提交合并，以及持续集成的工具赋能，实现自动化代码的编译、自动化单元测试和自动化的集成测试，并更具数据反馈判断代码质量趋势和项目风险，同时可以判断增量代码的合理性，负责代码的成员可以及时收到反馈结果。

持续部署和持续交付

持续部署（CD）经过代码构建、单元测试和集成测试后，形成产品化的程序制品、持续交付通过自动化技术手段将具备准出条件的程序制品发布至生产环境。

持续部署和持续集成、持续交付的区别

• 流程上：
  持续交付阶段，将程序制品上传制品库，形成产品级制品，交由运维团队进行生产环境部署活动。
  持续部署阶段，将产品级制品，从制品库发布至生产环境。
  持续集成：进行代码增量交付质量可靠的代码。
• 本质区别：
  • 持续集成：解决软件开发过程中开发能力水平伸缩的问题。
  • 持续部署：对代码交付物进行全面检查，形成产品级制品。对质量复盘，形成代码质量的终态闭环。
  • 持续交付：用来优化项目交付和内部管理的过程，通过产品的反馈对项目评价。

发布策略

• 单批次发布
  也称粗暴发布，传统的发布方式；
  优点：部署流程和发布过程简单，成本低。
  缺点：导致业务中断、较差的用户体验。
  场景：适用于非生产环境或非关键业务。

• 金丝雀发布
  也称灰度发布，先发布一部分服务器，进行验证，合适就慢慢进行流量切分。
  优点：对业务连续性和用户体验的影响较小。
  缺点：对于持续部署的要求较高。
  场景：超大规模的系统发布；

• 波浪发布

  • 也称为滚动发布，在金丝雀的基础上优化和改进，通过流量切分的方式进行班的流量转移。通过初始化发布服务器比例方式进行循环发布，直至所有新版本发布结束。
  • 优点：发布过程中尽可能不影响用户体验，同事保持较高的业务连续性
    缺点：发布速度较慢，需要较强的持续部署能力和较为完善的部署支撑工具。
  • 场景：系统的扩缩容；业务连续性极高的系统，以及用户体验不能中断的场景。

• 蓝绿发布
  需要具备两套相同的系统，面向用户提供服务的叫绿色，面向DevOps价值交付个能力子域且即将准备发布，称为蓝色系统。两套系统区别在于系统版本和对外服务情况。
  优点：发布和回滚快速，
  缺点：蓝色系统不对外提供服务，造成资源浪费。蓝绿角色衔接问题，导致业务短暂中断。
  场景：适合弹性伸缩的容器云场景，能够容忍短暂的业务中断和不佳的用户体验

• 红黑发布

  • Netflix 公司采用的发布手段，利用AWS的特性。先创建新服务器，测试不通过，修正后，销毁新生成的服务器集群，通过，就指向新的集群，并销毁旧集群。
    优点：业务系统服务始终在线，同时采用不可逆的方式进行发布。红黑发布和蓝绿发布的却在于，不需要保持冗余的在线服务。

• 特性开关发布

  • 针对关键功能或者特定场景，有功能开关、A/B测试开关，运维开关和权限开关。
    • 功能开关，功能版本和功能部署进行分离，利用代码中的功能逻辑控制对外服务的启用和关闭。
      优点：实现面向业务和面向客户的解耦，新版本的升级切换和回滚的效率极高；
      缺点：切换针对全量，如果新版有缺陷，容易对业务连续性和用户体验造成影响。对代码存在全能乳问题，代码逻辑变复杂不利于维护。
    • A/B测试开关：又叫实验开关，同一时间内提供多个版本对用户进行服务；利用负载均衡并通过流量路由进行流量的智能分发
    • 运维开关：通过运维的角度对系统进行控制；场景：金融西戎的促投放限制，电商商品的抢购场景中的sku控制。
    • 权限开关：对于某些功能的限制，仅向付费用户开放的一些功能。

微服务部署

微服务架构（Microservice Architecture）是一种全新的架构，通过将功能分散到各个离散的服务中，实现对解决方案的解耦，从而降低系统的耦合度；就是把一个大型的应用程序或服务进行拆分，形成多个微服务程序，可扩展单个组件而不是整个应用程序堆栈，从满足服务等级协议要求。

• 传统开发模式：单体式开发方式。
  优点：开发模式简单便于对代码进行集中式管理。
  缺点：所有人都在一个项目里，容易效率低下；所有代码功能耦合，代码维护困难；任何修改都全局代码构建，构建不灵活；牵一发动全身，无法满足高并发场景的业务需求。
• 微服务开发模式：通过分布式服务进行系统的业务功能整合；每个系统功能实现一个服务，模块之间极少存在框架的依赖。
  优点：内部分工明确，快速进行增量交付；模块之间解耦，保证业务的连续性；根据访问量动态地调整服务的数量。根据模块的不同使用场景，选择不同的语言和框架；
  缺点：拆分的过小，运维困难，网络链路见交互过多，服务的通信成本增加；随着服务的弹性伸缩，对代码的管理难度增加，对开发员要求高，成本会增加；

与DevOps的关系
微服务架构可以更快的提升敏捷能力
微服务架构可以进行弹性的持续交付
微服务架构可以缩短测试周期，提升测试质量