DevOps - 杂记

01 - 10

01 - Do the right thing!

在实践中，很难时刻关注目标并审视自己。
如果将DevOps看做是一个工具箱，那么就需要思考并从中找出合适的工具，来正确应对当前工作。
要确保在做正确的事情，而不是在不理解问题的前提下实现想法。
虽然有Sprint回顾会议机制，用来捕获潜在的改进空间，但往往没有真正地执行。

  • 是否在做正确的事？
  • 是否在正确的路上？
  • 应该以怎样的积极行动来敏捷地面对？

02 - PCDA循环与DevOps

PDCA循环是一种管理方法，主要用于在企业和商业活动中进行持续生产改善，并采取相应的控制措施。
这一方法将业务分为Plan(计划)、Do(执行)、Check(检查)和Act(处理)四个阶段来进行，在执行改善措施之后，又回到Plan(计划)阶段，如此循环往复。

  • P (Plan) 计划：包括方针和目标的确定，以及活动规划的制定。
  • D (Do) 执行：根据已知的信息，设计具体的方法、方案和计划布局；再根据设计和布局，进行具体运作，实现计划中的内容。
  • C (Check) 检查：总结执行计划的结果，分清哪些对了，哪些错了，明确效果，找出问题。
  • A (Act）处理：对总结检查的结果进行处理，对成功的经验加以肯定，并予以标准化；对于失败的教训也要总结，引起重视。对于没有解决的问题，应提交给下一个PDCA循环中去解决。
    以上四个过程不是运行一次就结束，而是周而复始的进行，一个循环完了，解决一些问题，未解决的问题进入下一个循环，阶梯式上升。
    全面质量管理活动的全部过程，就是质量计划的制订和组织实现的过程，这个过程就是按照PDCA循环，不停顿地周而复始地运转的。

关于PDCA的现代观点

  • P（Planning）——包括三小部分：目标（goal）、实施计划（plan）、收支预算（budget）。
  • D（design)——设计方案和布局。
  • C（4C)——4C管理：Check（检查）、Communicate（沟通）、Clean （清理）、Control（控制）。
  • A（2A)——Act（执行，对总结检查的结果进行处理）、Aim（按照目标要求行事，如改善、提高）。

与DevOps的关系

实施DevOps需要以PDCA的方式循环进行，在DevOps中，敏捷开发方法是实现PDCA循环的方法之一。
也就是说，DevOps是融合在业务中的持续性的改善和实践，而不是为了一次性完成所有的改善。

03 - 组织形式与DevOps

康威定律：设计系统的组织，其产生的设计等同于组织的沟通结构。
通过引入DevOps的工具和文化，能够使系统架构和组织结构同时发生变化。

04 - 在DevOps中应用Docker

构建功能单一的轻量级容器镜像

  • 容器以功能为单位进行分割，内容精简，缩小镜像
  • 容器之间尽量松耦合，消除容器内部对环境的依赖因素，提高通用性
  • 容器镜像本身不应保存与具体环境相关的信息

05 - From Traditional to Future

06 - DevOps技能图谱

仅作为参考，实际情况差异巨大。

不同成长阶段对技能的需求是不同的，无法准确用一张图来表示合适的内容。
大而全的技能图谱，不是为具体实施场景所准备的，而且里面甚至包括了过时的信息，不适合作为了解的途径。
这种技能图谱中的很多知识点、工具和技能其实不是现在就必须掌握的，重点是要掌握实际实施所必须的最少必要知识，先开展工作，然后在后期工作中按照需求、循序渐进地接触和使用。。
什么都想接触都想了解，效果必然很差，浪费时间和精力。

07 - 分支策略

制定分支的创建规则和使用规则，避免随意创建新分支导致的分支混乱、难以区分和回溯等问题。

  • 在什么时候需要使用分支？
  • 在什么时候合并到哪个分支？
  • 在不同的环境中分别使用哪个分支？
  • 在修改bug或者添加新功能时使用哪个分支？
  • ......

08 - DevOps几个关键点

  • 系统思考（将开发、测试、运维等环节之间的流程视为一条管道，从整体分析、定位和解决问题）
  • 增强反馈回路
  • 培养不断试验和学习的文化
  • 积极传播信息促进团队和个人成长

09 - 信息共享与管理

只有积极地传播和共享信息，才能推进DevOps的实施，提高团队的战斗力

  • 传统的方式：以文件形式存储在一台共享服务器上，存在难于搜索内容、无法获知更改信息和文件实时状态等问题
  • Web方式：Wiki、Confluence、看板等，易于创建和修改，能够快速准确找出所需信息
  • 代码库方式：信息文件存储在代码库，能够准确获知信息内容的状态和变化，以及历史信息

10 - 管理工作技术化

  • 需求失真，不透明，太抽象，需求管理混乱：明确唯一入口、团队共商共建、可视化、数据化等
  • 代码质量差：代码扫描自动化、在CI环节限制、评审策略化等
  • 测试反复，人力资源缺失：测试自动化、采用高效工具RobotFramework，Postman等
  • 版本零散、分支混乱、发布环境不一致：明晰的管理策略（代码、分支、环境）
  • 流程臃肿、数据繁杂，难以查看：可视化流程和数据
  • ......

11 - 20

11 - CheatSheet - devops-tutorial

https://intellipaat.com/blog/tutorial/devops-tutorial/

  • DevOps Tutorial – Learn DevOps from Experts
  • Ansible Tutorial – Learn Ansible from Experts
  • DevOps and Agile
  • DevOps Tools
  • Introduction to DevOps
  • Jenkins Tutorial – What is Jenkins?
  • Docker Tutorial for Beginners – What is Docker?
  • Puppet Tutorial
  • A Thorough Guide to Basic Git Commands and the Command-line Interface
  • Git Tutorial - Learn Git
  • Docker Cheat Sheet
  • Chef Cheat Sheet
  • GIT Cheat Sheet
  • Ansible Basic Cheat Sheet
  • Jenkins Cheat Sheet
  • Kubernetes Cheat Sheet
  • Puppet Cheat Sheet

12 - 构建个人本地开发环境

在个人计算机中搭建一个精简版的、与生产环境基本一致的本地开发环境，既不会占用团队公共环境的资源，也可以缩短等待时间，从整体上提高效率。
一般包括Git、开发语言、IDE、VirtualBox（Docker）等工具。
本地开发环境的适用场景：

  • 从应用程序开发的初期到单元测试阶段
  • 原型开发
  • 对风险或影响较大的变更进行前期调查
  • 确认需要完全独占环境的工作内容

13 - 微服务命名

微服务名称（Service Name)采用三段式的命名规则，中间使用短横线（－）分隔，即 xxxx-xxxx-xxxx形式
整体使用英文拼写，单词间不要 使用空格和下画线（＿），全部使用小写字母
如果微服务仅供组织内部使用，可以将应用 或项目名称作为一级服务名

一级服务名为组织名称，如baidu
二级服务名为应用或项目的名 称，如tieba
三级服务名为功能模块的名称，如auth

正确的示例如下(仅举例说明) ：

baidu-tieba-auth
eos-order-cancel 
org-open-platform-proxy

错误的示例如下：

org-open-platform proxy［错误说明：空格］ 
org_open_platform-proxy［错误说明：下画线］ 
org-open-PLATFORM-proxy［错误说明：大写］

14 - CI Pipeline

15 - 限制信息流动的因素

  • 权责过于分明：不愿轻易踏足其他领域
  • 流程繁琐：漫长的处理和反馈
  • 严格的安全限制：担心违规，限制分享
  • 精细的权限管理：一些基础操作 花费额外精力

16 - 问题产生的因素

所谓“难度”：

  • 稀缺性 ---》 资源限制 -----》 开源共享
  • 规模性 ---》 数量庞大，量变引发质变 -----》 标准化
  • 重复性 ---》 产出低效 -----》 自动化
  • 特殊性 ---》 全新未知 -----》基于标准的定制化

17 - 一些Ops

  • DevOps 软件的构建与交付，更快地交付软件
  • SecOps 以安全为核心，网络和应用程序的安全性
  • DevSecOps 融合了安全的DevOps
  • GitOps 致力于持续交付，环境的版本化历史
  • NetOps 确保网络能够支持数据流
  • ITOps 专注于软件交付之外的运维任务
  • DataOps 更快地交付数据
  • MLOps 更快地交付机器学习模型
  • AIOps 更智能地增强IT运维

18 - 周期性的迭代

  • 看板： 短周期，一般24小时，也就是一天，每日站会
  • Scrum：一个sprint周期大概2到4周
  • SAFe（Scaled Agile Framework，大规模敏捷框架）：多个Scrum Sprint

19 - 滚动升级

  • 避免让最终用户停机
  • 极低的停机时间
  • 国际企业可能并没有合适的时间窗口来处理升级，滚动升级可能是唯一的选择。

20 - 大规模部署

- 服务日志：统一搜集日志，快速针对某个业务问题定位到具体日志
- 服务监控与健康检查：自动化获取数量众多的实例运行状态
- 服务网络：避免网络复杂化和管理琐碎化，有效管理IP、端口等资源在满足服务隔离要求下实现服务互通

- 服务发现：自动化探测服务并加入集群，及时剔除不可用的服务
- 服务调度与编排：根据优先级和使用策略调度资源，编排和定义服务，实现定制化服务部署和可控频率的滚动更新
- 服务自动伸缩：自动的资源伸缩能力，应对性能问题

- 负载均衡：切换平稳，不影响业务运行，终端客户无感知
- 微服务支持：简化传统集群的部署结构，降低部署成本

- 数据存储：采用网络存储来应对容器实例非持久化

21 - 30

21 - DevOps的6C周期

- Continuous Business Planning    持续经营计划
- Collaborative Development    协作开发
- Continuous Testing    持续测试
- Continuous Release and Deployment    持续发布与部署
- Continuous Monitoring    持续监控
- Collaborative Customer Feedback & Optimization    协同客户反馈和优化

22 - ChatOps

所有操作和处理都会通知到即时通讯工具，可以通过聊天工具来追踪、确认和推动DevOps全链路的状态。
一些常见工具

23 - 镜像仓库规划

如果在公司或组织内部进行基于容器的私有云建设，那么往往同时也需要建立一个私有的镜像仓库。
镜像仓库是容器化的关键组成部分，如果镜像仓库服务异常，那么就无法发布和部署新版本。
一些镜像仓库规划的建议

  • 除了建立容灾备份、实现负载均衡外，还需要建立集群，防止镜像服务异常
  • 利用Jenkins任务自动化清理旧版本镜像，节省存储空间，简化管理
  • 基于简单可靠的原则，测试和生产环境可以共用一套镜像仓库
  • 如果测试和生产环境分别建立了镜像仓库，就需要特别关注“复制规则的制定”

24 - 精益、敏捷和IT服务管理同DevOps的结合

IT管理框架体系不断地发展，融合了其他理念。

  • 精益IT则是ITSM接受精益理念洗礼后的一个产物。
  • 敏捷理念，例如通过迭代、站会、燃尽图、最简可行产品使得开发周期变得更短、更快，实现小步快跑，即在高频率的情况下交付小体量的产品
  • 在DevOps实践中，ITSM的服务台、事件管理、变更管理、可用性管理等可以与精益和敏捷的很多流程理念相结合。

25 - 可视化

  • 创建并使用“可视化管理系统（VMS）”，简化工作的复杂程度并清楚掌握工作量，例如看板等任何辅助性的视觉工具
  • 将任务的状态按计划(To do)、执行中(Doing)和完成(Done)进行分类，帮助团队了解所有工作任务的类别，如项目、功能和问题
  • 分类别的工作可视化能实现工作量的管理和任务优先级的排序：业务项目、IT项目、变革请求和计划外工作

26 - 价值流

  • 工作任务存在流动性，在组织中从一个部门流向另外一个部门，需要重点关注流动的速度和体量
  • 流在某一个环节一旦受阻，会引起无谓的时间浪费甚至返工
  • 通过开发自己的价值流程图(VSM)来明确价值流，可以从工作流和价值的角度去思考并能够及时鉴别阻碍流的障碍和瓶颈

27 - 反馈机制

  • 在现实工作中，很多事情都无法做到一步准确到位，团队也都会犯错误
  • 反馈机制对于高效协作的团队来说，有助于尽早地发现问题并避免重复犯错，从行为和文化方面诠释了DevOps 原则中的高效沟通和通力协作
  • 从开发到运维、从运维到开发、从开发到业务这些环节中探索并建立有效的反馈机制

28 - 瓶颈

  • 瓶颈是由于太多的工作积压造成的
  • 工作量过于繁重将导致工作完成延时或产生错误，影响整个工作流，会把错误传递到工作流下游，并以返工的工作项返回到工作流的上游，最终造成工作积压
  • 如何最小化在制品(WIP)？如何鉴别、分析并最终移除瓶颈？

29 - 精益元素

  • 精益是DevOps实践的重要组成部分，包括消除浪费、返工、上游、下游、等待、避免错误、去现场、改善以及推拉机制等等。
  • 精益理念可以有效地起到加速流程并减少错误的作用。

30 - 多功能跨界团队

  • 工作中的孤岛思维、任务交接的拖延、不断的事态升级和重新排布优先级等一系列问题都会阻碍工作流的顺畅
  • 高效协作离不开团队之间专注性的、知识和技能的分享
  • 打造高效团队与每位成员的积极努力和全身心的投入是密不可分的
  • 多功能跨界团队实现对自身工作的测试并实施低风险级别的变更，避开工作流的阻碍（耗时耗力的检测和控制）

31 - 40

31 - 商业优先级

  • 业务部门是流的开端并决定商业优先级，不但决定商业价值，而且承担产品负责人(PO)的角色
  • 开发(Dev)和运维(Ops)必须学会如何同业务(Biz)通力协作
  • 通过告知业务部门的当前状态、将其参与到DevOps的过程当中以及良好沟通，与业务部门共同做出有效的决策
  • 业务部门共享和反馈信息给开发和运维部门，完成编排工作优先级并在新的特性、功能以及维护工作中找到平衡

32 - 集成测试

  • 团队将学会把测试尽早地参与进来。只有每项任务都高质量完成，才能避免错误流入下游
  • 团队需要学会如何执行“集成测试”，并在工作流的每一个环节中参与测试活动

33 - 自动创建

  • 团队通过可以开发工具，培训干系人使用工具的方式来提高效率。
  • 工具在设计中考虑人员和流程的结合，如果流程是杂乱无章的，不能有效支持工作流的顺畅运转，那么开发的工具就是失败的
  • 在决定开发和使用工具前，参考完整的商业案例和培训方案
  • 有效地培养人员、流程和技术相互结合的全局观
  • 如果没有业务人员充分的参与，将导致业务方面的瓶颈

34 - 用户反馈

  • 用户使用应用和服务的数据，或者通过问询和调查客户获取
  • 为开发新的软件或应用提供了极具价值的信息

35 - 敏捷元素

  • 站会讨论
  • 最简可行产品(MVP. Minimum Viable Products)
  • Scrum
  • 敏捷中的迭代(Sprint)和速率(Velocity)
  • 团队可以管理工作量，并且在没有错误的前提下快速部署小的功能组件包

36 - 文化

  • 文化深入到了团队每一个人的行为和态度中。DevOps的主旨之一是高效的团队协作沙盘演练中会遇到很多关于文化方面的讨论。沙盘教练将讲述
  • 知识分享的理由和必要性
  • 给予和接纳反馈的理由的必要性

37 - 团队协作

  • 真正能够让团队在一起实现高效的工作并不容易，需要每一个成员都掌握团队建设的技巧和自我提升的能力
  • 学会如何组织站会、如何进行回顾以及如何总结经验
  • 有效方式是在开放和安全的环境中分享知识、给予或接纳反馈意见
  • 信任是团队协作必不可少的前提，通过开放式沟通和通力协作建立信任
  • 在现实工作中克服这些复杂的障碍则需要管理层面对变革表现出强大的领导力和决心

38 - 指标

  • 大多数的IT指标都是偏重于组织内部的指示项的，需要建立新的实效性和长期性指标
  • 通过不同的方式衡量业绩，明确对“完成”的定义，应该和实现业务价值相互关联，衡量和激励
  • 过多的行为指标（站会、移除瓶颈、缩减回退工作、部署增长的数量，某个阶段错误减少的百分比等）并不保证业绩的提升

39 - 业务角色

  • 需要让业务部门体验并看到DevOps实践给企业带来的优势
  • 业务部门人员参加站会和回顾会议，意识到不应把过多的工作强压到IT工作流中，以便实现最小化在制品(WIP)
  • 业务人员承担产品负责人的角色，通过简化工作和缩减工作量来避免可能造成的瓶颈和错误，因此创建真正的业务优先级并以此安排事项尤为重要
  • 产品负责人不应该只关注具有创新性的产品和功能，还需重视维护工作和移除技术债务等

40 - 过程管控

  • 自动化的过程管控，让开发、质量、运维等不同角色之间的沟通协作更加顺畅
  • 研发交付质量的检测从原有的保障部署结果(是否成功)延伸到源码质量检查、代码安全审计、测试覆盖度等过程
  • 建立能效管控体系，针对敏捷研发过程建立数字化度量模型
  • 针对重点指标建立评价指标，结合一定的制度管控和数据分析，实现自动化的技术管控
  • 交付过程的持续优化既包括DevOps平台的优化，也包括研发交付流程、标准规范等方面的优化

41 - 50

41 - DevOps体系

  • 从最初“一组过程、方法与系统组合的统称”发展为“一套集文化理念、实践和工具于一身的体系
  • 本身系统化、整体性的设计思想，既包括软件全生命周期的系统化考虑，也蕴含IT管理过程中的多方诉求
  • DevOps与敏捷开发天然互补，契合追求快速迭代的模式
posted @ 2017-01-16 08:02  Anliven  阅读(1309)  评论(0)  编辑  收藏  举报