DevOps实践指南(目录)

DevOps实践指南(目录)

    • [Part 1 DevOps 介绍](#Part 1 DevOps 介绍)
    • [Part 2 从何处开始](#Part 2 从何处开始)
    • [Part 3 第一步 :流动的技术实践](#Part 3 第一步 :流动的技术实践)
    • [Part 3 第一步 :流动的技术实践 二](#Part 3 第一步 :流动的技术实践 二)
    • [Part 4 第二步 :反馈的技术实践](#Part 4 第二步 :反馈的技术实践)
    • [Part 4 第二步 :反馈的技术实践 二](#Part 4 第二步 :反馈的技术实践 二)
    • [Part 5 第三步 :持续学习与实验的技术实践](#Part 5 第三步 :持续学习与实验的技术实践)
    • [Part 6 集成信息安全、变更管理和合规性的技术实践](#Part 6 集成信息安全、变更管理和合规性的技术实践)

Part 1 DevOps 介绍

入口

        精益运动
        敏捷宣言
    1. 敏捷、持续交付和三步法
        1.1 制造业价值流
        1.2 技术价值流
            1.2.1 聚焦于部署前置时间
            1.2.2 关注返工指标------%C/A
        1.3 三步工作法:DevOps 的基础原则
    2. 第一步:流动原则
        2.1 使工作可见
        2.2 限制制品数
        2.3 减小批量大小
        2.4 减少交接次数
        2.5 持续识别和改善约束点
        2.6 消除价值流中的困境和浪费
        2.7 小结
    3. 第二步:反馈原则
        3.1 在复杂系统中安全地工作
        3.2 及时发现问题
        3.3 群策群力,战胜问题获取新知
        3.4 在源头保障质量
        3.5 为下游工作中心而优化
        3.6 小结
    4. 第三步:持续学习与实验原则
        4.1 建立学习型组织和安全文化
        4.2 将日常工作的改进制度化
        4.3 把局部发现转化为全局优化
        4.4 在日常工作中注入弹性模式
        4.5 领导层强化学习文化
        4.6 小结

Part 2 从何处开始

入口

    5. 选择合适的价值流作为切入点
        5.1 绿地项目与棕地项目
        5.2 兼顾记录型系统和交互型系统
        5.3 从最乐于创新的团队开始
        5.4 扩大 DevOps 的范围
        5.5 小结
    6. 理解、可视化和运用价值流
        6.1 确定创造客户价值所需的团队
        6.2 针对团队工作绘制价值流图
        6.3 组建专门的转型团队
            6.3.1 拥有共同的目标
            6.3.2 保持小跨度的改进计划
            6.3.3 为非功能性需求预留 20%的开发时间,减少技术债务
            6.3.4 提高工作的可视化程度
        6.4 用工具强化预期行为
        6.5 小结
    7. 参考康威定律设计组织结构
        7.1 组织原型
        7.2 过度职能导向的危害("成本优化")
        7.3 组建以市场为导向的团队("速度优化")
        7.4 使职能导向有效
        7.5 将测试、运维和信息安全融入日常工作
        7.6 使团队成员都成为通才
        7.7 投资于服务和产品,而非项目
        7.8 根据康威定律设定团队边界
        7.9 创建松耦合架构,提高生产力和安全性
        7.10 小结
    8. 将运维融入日常开发工作
        8.1 创建共享服务,提高开发生产力
        8.2 将运维工程师融入服务团队
        8.3 为每个服务团队分派运维联络人
        8.4 邀请运维工程师参加开发团队的会议
            8.4.1 邀请运维工程师参加每日站会
        8.4.2 邀请运维工程师参加回顾会议
        8.4.3 使用看板图展示运维工作
        8.5 小结

Part 3 第一步 :流动的技术实践

入口

    9. 为部署流水线奠定基础
        9.1 按需搭建开发环境、测试环境和生产环境
        9.2 应用统一的代码仓库
        9.3 使基础设施的重建更容易
        9.4 运行在类生产环境里才算"完成"
        9.5 小结
    10. 实现快速可靠的自动化测试
        10.1 对代码和环境做持续构建、测试和集成
        10.2 构建快速可靠的自动化测试套件
            10.2.1 在自动化测试中尽早发现错误
            10.2.2 尽可能并行地快速执行测试
            10.2.3 先编写自动化测试
            10.2.4 尽量将手动测试自动化
            10.2.5 在测试套件中集成性能测试
            10.2.6 在测试套件中集成非功能性需求测试
        10.3 在部署流水线失败时拉下安灯绳
        10.4 小结

Part 3 第一步 :流动的技术实践 二

入口

    11. 应用和实践持续集成
        11.1 小批量开发与大批量合并
        11.2 应用基于主干的开发实践
        11.3 小结
    12. 自动化和低风险发布
        12.1 自动化部署流程
            12.1.1 应用自动化的自助式部署
            12.1.2 在部署流水线中集成代码部署
        12.2 将部署与发布解耦
            12.2.1 基于环境的发布模式
            12.2.2 基于应用的发布模式更安全
        12.3 持续交付和持续部署实践的调查
        12.4 小结
    13. 降低发布风险的架构
        13.1 能提高生产力、可测试性和安全性的架构
        13.2 架构原型:单体架构与微服务
        13.3 安全地演进企业架构
        13.4 小结

Part 4 第二步 :反馈的技术实践

入口

    14. 建立能发现并解决问题的遥测系统
        14.1 建设集中式监控架构
        14.2 建立生产环境的应用程序日志遥测
        14.3 使用遥测指导问题的解决
        14.4 将建立生产遥测融入日常工作
        14.5 建立自助访问的遥测和信息辐射器
        14.6 发现和填补遥测的盲区
            14.6.1 应用程序和业务度量指标
            14.6.2 基础架构度量指标
            14.6.3 显示叠加的指标组合
        14.7 小结
    15. 分析遥测数据以更好地预测故障和实现目标
        15.1 用均值和标准差识别潜在问题
        15.2 异常状态的处理和告警
        15.3 非高斯分布遥测数据的问题
        15.4 应用异常检测技术
        15.5 小结
    16. 应用反馈实现安全部署
        16.1 通过遥测使部署更安全
        16.2 开发和运维共同承担值班工作
        16.3 让开发人员跟踪工作对下游的影响
        16.4 让开发人员自行管理生产服务
        16.5 小结

Part 4 第二步 :反馈的技术实践 二

入口

    17. 将假设驱动的开发和A/B测试融入日常工作
        17.1 A/B 测试简史
        17.2 在功能测试中集成 A/B 测试
        17.3 在发布中集成 A/B 测试
        17.4 在功能规划中集成 A/B 测试
        17.5 小结
    18. 建立评审和协作流程以提升当前工作的质量
        18.1 变更审批流程的危险
        18.2 "过度控制变更"的潜在危险
        18.3 变更的协调和排程
        18.4 变更的同行评审
        18.5 人工测试和变更冻结的潜在危害
        18.6 利用结对编程改进代码变更
        18.7 消除官僚流程
        18.8 小结
        18.9 第四部分总结

Part 5 第三步 :持续学习与实验的技术实践

入口

    19. 将学习融入日常工作
        19.1 建立公正和学习的文化
        19.2 举行不指责的事后分析会议
        19.3 尽可能广泛地公开事后分析会议结果
        19.4 降低事故容忍度,寻找更弱的故障信号
        19.5 重新定义失败,鼓励评估风险
        19.6 在生产环境注入故障来恢复和学习
        19.7 创建故障演练日
        19.8 小结
    20. 将局部经验转化为全局改进
        20.1 使用聊天室和聊天机器人自动积累组织知识
        20.2 软件中便于重用的自动化、标准化流程
        20.3 创建全组织共享的单一源代码库
        20.4 运用自动化测试记录和交流实践来传播知识
        20.5 通过确定非功能性需求来设计运维
        20.6 把可重用的运维用户故事纳入开发
        20.7 确保技术选型有助于实现组织目标
        20.8 小结
    21. 预留组织学习和改进的时间
        21.1 偿还技术债务的制度化惯例
        21.2 让所有人教学相长
        21.3 在 DevOps 会议中分享经验
        21.4 传播实践的内部顾问和教练
        21.5 小结
        21.6 第五部分总结

Part 6 集成信息安全、变更管理和合规性的技术实践

入口

    22. 将信息安全融入每个人的日常工作
        22.1 将安全集成到开发迭代的演示中
        22.2 将安全集成到缺陷跟踪和事后分析会议中
        22.3 将预防性安全控制集成到共享源代码库及共享服务中
        22.4 将安全集成到部署流水线中
        22.5 保证应用程序的安全性
        22.6 确保软件供应链的安全
        22.7 确保环境的安全
        22.8 将信息安全集成到生产环境遥测中
        22.9 在应用程序中建立安全遥测系统
        22.10 在环境中建立安全遥测系统
        22.11 保护部署流水线
        22.12 小结
    23. 保护部署流水线
        23.1 将安全和合规性集成到变更批准流程中
        23.2 将大量低风险变更重新归类为标准变更
        23.3 如何处理常规变更
        23.4 减少对职责分离的依赖
        23.5 确保为审计人员和合规人员留存文档和证据
        23.6 小结
        23.7 第六部分总结
    24. 行动起来------本书总结
相关推荐
青木沐1 小时前
Jenkins介绍
运维·jenkins
WTT00111 小时前
2024楚慧杯WP
大数据·运维·网络·安全·web安全·ctf
苹果醋32 小时前
React源码02 - 基础知识 React API 一览
java·运维·spring boot·mysql·nginx
日记跟新中2 小时前
Ubuntu20.04 修改root密码
linux·运维·服务器
唐小旭2 小时前
服务器建立-错误:pyenv环境建立后python版本不对
运维·服务器·python
BUG 4042 小时前
Linux——Shell
linux·运维·服务器
大霞上仙3 小时前
Linux 多命令执行
linux·运维·服务器
冷心笑看丽美人3 小时前
探索 Samba 服务器:搭建跨平台文件共享的桥梁
运维·服务器
晨欣3 小时前
Kibana:LINUX_X86_64 和 DEB_X86_64两种可选下载方式的区别
linux·运维·服务器