devops实践指南 - 读书笔记
****************************************************************************
从成本优化 到 效率优化
从职能型组织 到 业务型组织
团队成员往全栈通才发展
松耦合业务架构 小团队运作
云平台是devops的基础
垂直运维工程师
→ 水平运维工程师
运维联络人
自动化测试工具，版本控制系统，微服务都是Devops的基础
单元测试 → 验收测试 → 集成测试
持续集成，前提是自动化测试，持续集成+基于主干的开发模式
上线出现问题有拉安全绳的策略
开发 → 测试 → 预发布(该步骤可省略) → 生成
开发、测试、运维人员都能参与到部署生成环境下
将部署与发布解耦
金丝雀发布 → 环境发布 蓝绿发布
→ stage1 → stage2 → stage3
内部用户 小部分外部用户 大部分外部用户
基于环境发布 基于应用发布
应用发布
特性开关 - 将1%的用户发布新特性并做隐性调用，观察新特性的工作负载 → 提高用户的访问频率，增加用户基数 → 全部隐性开放 → 全部显性开放
黑启动
解耦集中式系统的实践方法：
构建紧耦合的独立系统 → 固定API
↑
集中式系统开发固定API
****************************************************************************
反馈机制：
事件路由器 → 目的地 → 图形化
存储 告警
↑
事件 ← 业务逻辑
日志 ← 应用系统
指标 ← 操作系统
← 硬件
通过小批量更快捷的部署方式，提供代码部署的安全感
集成 → 部署 → 验证 → 上线发布 → 存储问题 → 修复并上线
→ 回退
→ 无问题
****************************************************************************
实验验证 A/B测试
全链路监控机制
建立端到端的反馈机制，提高客户满意度
使用变更审批 / 同行审批 定义选择评审的标准
结对编程 到 代码审核的演进
持续学习与实践
固化故障案例，积累经验，形成知识库
组件应该具备降级的能力
故障演练 - 故障注入
观点：人为错误是无法避免的，最终都是工具的问题，工具的鲁棒性强不强决定服务的高可用、高可靠能力
不职责的事后故障分析
统一的代码仓库
****************************************************************************
网友评论