[2022 China DevOpsDays线上峰会]：中小团队的云原生Devops之路 - 潘野

中小团队的云原生DevOps之路

DevOps的四个组成部分

DevOps就是Ops做自动化
DevOps就是懂运维的开发
DevOps就是SRE
DevOps就是CI/CD

DevOps误区

大规模运行和管理您的基础设施及开发流程
加快软件开发与交付的速度
消除开发团队与运维团队之间的壁垒

DevOps职责

开发人员无需关心基础架构，专注于代码功能开发
运维人员从各种琐碎的手工配置中解脱出来，专注于基础架构的自动化，软件交付的自动化
通过DevOps的工具，开发人员与运维人员共同关注线上问题，能快速的定位与修复线上的bug

良好的DevOps评判标准

Deployment frequency（部署频率）
Lead time for changes（变更准备时间）
Change failure rate（变更失败率）
Mean time to restore service（服务恢复平均时间）

云原生定义

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生解决了DevOps中的哪些痛点

传统 DevOps	云原生 DevOps
基础架构自动化	Infra as code
应用生命周期管理	基于GitOps，不再依赖运维工程师
日志监控报警追踪	按需分配资源，避免浪费
效能指标	摆脱开火车的开发模式
PXE / 云厂商 API + Puppet/Salt	提供灵活多变的CI/CD流水线
Shell 脚本	测试通过即可上线
依赖运维工程师	通过prometheus, helm等工具将监控，报警与应用绑定
开发模式 - 开火车模式	开发为自己的应用负责
运维模式 - 夜班部署	DevOps为监控体系负责
运维配监控，开发看日志	Everyone care or No one care

DevOps的四个组成部分

文化
自动化
持续集成/持续交付
基础设施即代码

案例一：如何管理微服务中的数据库

业务中会使用到多种数据库，每种数据库特点不一样
不同的云，启动数据库方式不一样
每一个微服务都需要一个数据库
不同的环境，数据生命周期不一样
数据库数量指数级别增长，脚本式管理挑战巨大

解决方案

Kubernetes Operator
- Kubernetes Operator是将运维人员的操作代码化，同时利用Kubernetes强大的抽象来管理大规模的软件应用。
- Operator使用了Kubernetes的自定义资源（CustomResourceDefinition）扩展API机制。
- Operator基于Kubernetes的以下两个部分组成：
  - CustomResourceDefinition：对象的状态定义
  - Controller：监视CR类型并采取特定于应用的操作，确保当前状态与该资源的理想状态相符
多种数据库
- 常见的非关系数据库：Redis, MongoDB, Elasticsearch
- 常见的关系型数据库：MySQL, PostgreSQL
- 常见的队列服务：Kafka, RabbitMQ, Nats
分配数据库
- 为了提高资源利用率，多数情况下几个微服务会共享一个数据库服务器
- 将过程式管理变成对象化管理
- 数据库需求配置化，与应用打包在一个Helm chart中
- 不同环境，数据生命周期不一样：
  - 测试环境 – 测试时候清空
  - 准生产环境 – 数据保留
  - 生产环境 – 数据保留且备份
管理数据库
- 图形化数据库查询工具对开发人员来说非常重要
- 从安全角度出发，避免开发人员获取到数据库的用户名密码，而用本地查询工具直接连接数据库；同时也比较容易做数据库操作审计
- 使用vault这样的第三方工具来管理密码

案例二：四个关键指标

确定DevOps体系有效性
- Deployment frequency（部署频率）
- Lead time for changes（变更准备时间）
通过DevOps的体系提升研发效率
- Change failure rate（变更失败率）
- Mean time to restore service（服务恢复平均时间）