相关术语补充
CALMS原则
- Culture：团队思维（利益共享，风险共担）
- Automation：自动化思维
- Lean：精益思维
- Measurement：数据可度量&可视化
- Sharing：鼓励开发和运维直接互相分享
THE THREE WAYS原则
- DEV->OPS，局部服务于全局，避免短板效应，系统性思考
- DEV->OPS，OPS->DEV 反馈闭环，相互进步
- DEVOPS文化，在反馈闭环中，持续学习和进步
精益思维
- 最小可行性
- 单一关键指标
- 精益看板
- 风险管理
CI/CD
- 流水线操作
- 软件版本管理
- 软件依赖管理
- 内建代码测试
- 软件环境管理
- 热发布/零停机发布
- 灰度发布、蓝绿发布
构建Saas方法 - 12Factor
- 一份基准代码
- 声明软件依赖清单
- 在环境中配置软件参数
- 将后端服务作为附加资源
- 软件构建、发布、运行，相互隔离(可以基于版本快速回滚比如从release->v100)
- 基于一个或多个无状态进程运行应用（避免在进程中涉及有状态数据，比如粘性session）
- 基于端口提供服务（服务消费者调用服务服务提供者，同时对于的服务地址、端口信息需要录入到配置中心）
- 基于进程模型扩展（按需提供或者进程池模型），应用程序必须支持多机器跨进程工作，且推崇基于systemd进程、进程管理管控
- 易处理，快速启动&优雅终止，最大化健壮性（比如消息回退nack、停止网络监听&消息队列完成后续处理）
- 环境等价，软件版本、部署路径方式、日志生成目录等（开发可以基于vagrant、chef配置等无限接近生产环境）
- 日志，把日志作为事件流的汇总（日志文件只是存储格式，每个进程输出由运行环境截获，一并发送给到日志收集进程处理）
- 管理进程（后台管理进程环境同步，比如
php artisan、bundle exec rake db:migrate)
1. 工程师文化
- 信任、透明、高效、互助的沟通文化
- 交付速度=(功能特性x工程质量x交付风险)/交付时间
2. DevOps工程师（Development、Operations）
范围涉及：开发工具、版本管理工具、CI 持续交付工具、CD 持续发布工具、报警工具、故障处理。
2.1. 职责
- 管理应用全生命周期（需求、设计、开发、QA、发布、运行）
- 关注全流程效率提升，挖掘瓶颈点并将其解决
- 自动化运维平台设计和研发工作（标准化、自动化、平台化）
- 支持运维系统，包括 虚拟化技术、资源管理技术、监控技术、网络技术
2.2. 工作内容
- 设定应用生命管理周期制度，扭转流程
- 开发、管理 开发工程师/QA 工程师使用，开发平台系统
- 开发、管理 发布系统
- 开发、选型、管理 监控、报警系统
- 开发、管理 权限系统
- 开发、选型、管理 CMBD
- 管理变更
- 管理故障
3. SRE工程师（Site Reliability Engineering）
范围涉及：容量测量工具、Logging 日志工具、Tracing 调用链路跟踪工具、Metrics 性能度量工具、监控报警工具等。
3.1. 关注点
- 高扩展性：高扩展性是指当服务用户数量暴增时，应用系统以及支撑其服务（服务器资源、网络系统、数据库资源）可以在不调整系统结构，不强化机器本身性能 ，仅仅增加实例数量方式进行扩容。
- 高可用性：高可用性是指，应用架构中任何环节出现不可用时，比如应用服务、网关、数据库 等系统挂掉，整个系统可以在可预见时间内恢复并重新提供服务。
3.2. 职责
- 为应用、中间件、基础设施等提供 选型、设计、开发、容量规划、调优、故障处理
- 为业务系统提供基于可用性、可扩展性考虑决策，参与业务系统设计和实施
- 定位、处理、管理故障，优化导致故障发生相关部件
- 提高各部件资源利用率
3.3. 工作内容
- 管理变更
- 管理故障
- 制定 SLA 服务标准
- 开发、选型、管理 各类中间件
- 开发、管理 分布式监控系统
- 开发、管理 分布式追踪系统
- 开发、管理 性能监控、探测系统（dtrace、火焰图）
- 开发、选型、培训 性能调优工具
4. DevOps和SRE差别
- DevOps和SRE都会关心应用生命周期，特别是生命周期里面中变更和故障；
- DevOps首先是一种文化，后期逐渐独立成一个职位，SRE一开始就明确是一个职位，公司不一定需要SRE工程师，但需要DevOps工程师通常；
- 运维不等于DevOps，也不等于SRE，但后两者都需要较强的运维技能（一个误区就是运维=DevOps或者SRE)；
- SRE在一些专业领域的技能（计算机体系结构、高吞吐高并发、可扩展系统设计、复杂业务系统设计、性能优化等）要求要高于DevOps;
- SRE强调分析问题、解决问题能力，面对挑战，可以迎难而上，自驱学习；
- 从专业背景来看，无论是DevOps还是SRE，都需要研发背景，前者需要开发工具链，后者需要有较强架构设计经验。
- 如果有运维工程师想转型成为DevOps或者SRE，那么需要补上相关技术知识。
毕竟，不是会搭建一套Jenkins+Kubernetes 就可以自称为DevOps/SRE 工程师。
4.1. DevOps技术栈
- Dev：
- 编程语言：Python、Golang、PHP、Java
- 理论基础：软件生命周期（Application Life Cycle）、12 Factor、微服务、CICD思想
- Ops：
- Linux：基本命令、FHS、标准、发行版差异、历史
- 脚本：Bash/Python
- 基础服务：DHCP、NTP、DNS、SSH、iptables、systemd、LDAP、CMDB等
- Web应用服务：Nginx、HAProxy、LVS、F5
- 自动化：Fabric、Saltstack、Chef、Ansible
- 虚拟化：KVM、XEN、vSphere、Docker、Kubernetes、Mesos
- 基础设施：
- 代码仓库（Gitlab、Github）
- 日志收集（Logstash、Flume）
- 服务监控（Zabbix、Nagios）
- 配置管理（Etcd、Zk）
- 私有包管理（Nexus、Pypi、JFrog、Satajs）
- 权限管控（跳板机、堡垒机）、监控系统
- CI/CD继续集成和发布：Jenkins、Pipeline、Git、Git Hooks
4.2. SRE技术栈
- 理论基础：
- 计算机科学：计算机组成、计算机网络、操作系统、数据结构和算法、软件工程、数据库知识、计算机编程
- 精通Linux，熟悉Linux性能优化：stress、mpstat、iostat、netstat、sysstat、ps、top、atop、htop、vmstat等
- 熟悉TCP/IP协议
- 并发模型：并发、并行、多进程、多线程等
- 分布式理论、CAP、PACELC、BASE、Paxos、MapReduce等
- 资源模型：网络、内存、CPU、IO、扩展性设计
- 工程实践：
- 运维架构设计，运维资源评估，能够为场景决策合适方案
- 故障分析和处理
- 深入理解业务系统，包括业务团队使用的开发语言、框架、性能风险
- 性能优化升级，Linux性能优化、DB性能优化、网络性能优化、系统架构升级等
- 工具依赖：
- Tracing 链路追踪
- Metrics 度量工具
- Logging 日志系统
5. 小结
研发除转产品、业务、管理、架构，对运维有了足够的了解后，转DevOps和SRE工程师，也是一条不错的职业发展道路（前提是对基本知识的掌握是有足够的要求）！！
另外，devops ci/cd工具参考：https://opensource.com/article/18/12/cicd-tools-sysadmins