DevOps - Tips
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技能图谱
仅作为参考,实际情况差异巨大。
- https://github.com/TeamStuQ/skill-map/blob/master/data/map-DevOps.md
- https://www.infoq.cn/article/the-must-know-checklist-for-devops-and-sre
- https://www.infoq.cn/article/NpBtkovq8idXk-Z0yoby
不同成长阶段对技能的需求是不同的,无法准确用一张图来表示合适的内容。
大而全的技能图谱,不是为具体实施场景所准备的,而且里面甚至包括了过时的信息,不适合作为了解的途径。
这种技能图谱中的很多知识点、工具和技能其实不是现在就必须掌握的,重点是要掌握实际实施所必须的最少必要知识,先开展工作,然后在后期工作中按照需求、循序渐进地接触和使用。。
什么都想接触都想了解,效果必然很差,浪费时间和精力。
07 - 分支策略
制定分支的创建规则和使用规则,避免随意创建新分支导致的分支混乱、难以区分和回溯等问题。
- 在什么时候需要使用分支?
- 在什么时候合并到哪个分支?
- 在不同的环境中分别使用哪个分支?
- 在修改bug或者添加新功能时使用哪个分支?
- ......
08 - DevOps几个关键点
- 系统思考(将开发、测试、运维等环节之间的流程视为一条管道,从整体分析、定位和解决问题)
- 增强反馈回路
- 培养不断试验和学习的文化
- 积极传播信息促进团队和个人成长
09 - 信息共享与管理
只有积极地传播和共享信息,才能推进DevOps的实施,提高团队的战斗力
- 传统的方式:以文件形式存储在一台共享服务器上,存在难于搜索内容、无法获知更改信息和文件实时状态等问题
- Web方式:Wiki、Confluence、看板等,易于创建和修改,能够快速准确找出所需信息
- 代码库方式:信息文件存储在代码库,能够准确获知信息内容的状态和变化,以及历史信息
10 - 管理工作技术化
- 需求失真,不透明,太抽象,需求管理混乱:明确唯一入口、团队共商共建、可视化、数据化等
- 代码质量差:代码扫描自动化、在CI环节限制、评审策略化等
- 测试反复,人力资源缺失:测试自动化、采用高效工具RobotFramework,Postman等
- 版本零散、分支混乱、发布环境不一致:明晰的管理策略(代码、分支、环境)
- 流程臃肿、数据繁杂,难以查看:可视化流程和数据
- ......
11 - 20
11 - DevOps和Agile
如果说Agile是内功和心法的话,那么DevOps则是力量与招式。
Agile描述了一套价值观,却没有显式的把方法论体系化,而DevOps定义了一套方法论,把价值观蕴含在其实践中。
12 - DevOps标准与认证
《研发运营一体化(DevOps)能力成熟度模型》
- 由工信部直属单位中国信息通信研究院牵头
- 云计算开源产业联盟、高效运维社区和 DevOps 时代社区联合发起
- 携手国内互联网、电信、金融等行业领先企业百余位专家共同编制
- 全球首个 DevOps 标准,已在联合国直属标准化组织 ITU-T、中国工信部、中国通信标准化协会(CCSA)正式立项。
13 - 九问DevOps
“问题”一定是着某种具体的“目的与需求”来提问的,关于答案,没有正不正确,只有“合不合适”。
- 你对DevOps的理解是什么?
- 你认为DevOps的发展趋势是怎样的?
- 如果让你来组织或者引导一个DevOps项目的实施,你如何开展工作?
- 你将如何去说服或引领关键人(例如决策者、管理者、最终使用者、反对者等)赞同并支持建立DevOps机制?
- DevOps项目的实施后,落地了工具和方法,如何去评价DevOps的成效?
- 你获取和更新DevOps信息的途径和方式有哪些?最常用的是什么?
- 一套DevOps系统建立后,你认为如何保证这套系统的健康稳定的运转?
- 你在实施或运维DevOps过程中,遇到最大的困难是哪方面的?如何解决的?具体的方法是怎么?
- 你在推动和建立DevOps的过程中,投入最多精力和时间的是哪方面?为什么?
14 - CI Pipeline
15 - 限制信息流动的因素
- 权责过于分明:不愿轻易踏足其他领域
- 流程繁琐:漫长的处理和反馈
- 严格的安全限制:担心违规,限制分享
- 精细的权限管理:一些基础操作 花费额外精力
16 - 问题产生的因素
所谓“难度”:
- 稀缺性 ---》 资源限制 -----》 开源共享
- 规模性 ---》 数量庞大,量变引发质变 -----》 标准化
- 重复性 ---》 产出低效 -----》 自动化
- 特殊性 ---》 全新未知 -----》基于标准的定制化
17 - ITIL(information technology infrastructure library, 信息技术基础架构库)
- 贯穿软件生命周期的大型框架,用以管理复杂变更
- 很多大型成熟企业采用的一种实践
- 某些ITIL描述的实践可以直接转换成相对应的DevOps实践
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全链路的状态。
一些常见工具
- Slack:https://slack.com/
- 企业版微信:https://work.weixin.qq.com/
- 钉钉DingTalk:https://www.dingtalk.com/
- 微软Teams:https://docs.microsoft.com/zh-cn/microsoftteams/teams-overview
- Cisco Jabber:https://www.cisco.com/c/zh_cn/products/unified-communications/jabber/index.html
- 华为云WeLink:https://www.huaweicloud.com/product/welink.html
23 - 镜像仓库规划
如果在公司或组织内部进行基于容器的私有云建设,那么往往同时也需要建立一个私有的镜像仓库。
镜像仓库是容器化的关键组成部分,如果镜像仓库服务异常,那么就无法发布和部署新版本。
一些镜像仓库规划的建议
- 除了建立容灾备份、实现负载均衡外,还需要建立集群,防止镜像服务异常
- 利用Jenkins任务自动化清理旧版本镜像,节省存储空间,简化管理
- 基于简单可靠的原则,测试和生产环境可以共用一套镜像仓库
- 如果测试和生产环境分别建立了镜像仓库,就需要特别关注“复制规则的制定”
24 - 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
25 - Check List for DevOps
- 核心需求是什么?
- 当前公司的现状如何?是否具备实施DevOps的基础?
- 基本架构图和演进路线图如何?
- 需要耗费多少资源:人、时间、硬件、软件等?
- 用什么工具?当前业界主流使用什么工具、方法?优势和劣势是什么?
- 后续维护需要多大的成本?
- 如何降低开发适应性问题?
- 如何实现容器化?选择什么容器管理的工具?指定怎样的管理策略?
26 - 构建个人本地开发环境
在个人计算机中搭建一个精简版的、与生产环境基本一致的本地开发环境,既不会占用团队公共环境的资源,也可以缩短等待时间,从整体上提高效率。
一般包括Git、开发语言、IDE、VirtualBox(Docker)等工具。
本地开发环境的适用场景:
- 从应用程序开发的初期到单元测试阶段
- 原型开发
- 对风险或影响较大的变更进行前期调查
- 确认需要完全独占环境的工作内容
27 - IT服务设计与IT架构师
IT服务设计是企业IT服务战略落地的设计方法论以及具体解决方案的集合。
一个符合企业IT运营成本需求、低风险、易于维护并高可用性的IT服务的解决方案设计对企业来讲是至关重要的,而IT架构师就是能够帮助企业实现上述目标的人。
架构是应用架构设计方案来解决客户的实际问题,架构设计一般是由系统、应用和流程等部件组成的。
架构设计中也可能会包括更加广泛的产品、技术、服务、硬件和软件部件等。
而IT架构师是通过设计架构方案来解决客户实际问题的人。
部件(Components)是能够提供一个或一组特定功能的集合。
部件可以是服务器、网路 拓扑架构、应用软件、中间件平台、流程控制软件或服务管理软件等。
架构设计并不是简单部件相加的过程,要充分考虑部件的可重用性、部件的属性、方法、接口定义和部件之间的接口调用关系等。
IT架构师提供的解决方案是通过系统架构设计来展示和描述的。
包括操作系统的选型、存储和网络的界定、应用模块的具体逻辑定义和它们之间的接口调用关系等。
IT架构师侧重于方案设计阶段的工作,但也要全程参与项目的具体实施。
在方案实施过程中,作为与客户进行技术方面沟通的桥梁,并且对IT施工团队提供必要的技术指导和实施引导等。
确保具体实施过程是完全按照既定架构设计方案完成,并且还要在项目实施的具体技术公关上起到决定性的指导作用。
28 - 微服务命名
微服务名称(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[错误说明:大写]
行动是绝望的解药!
欢迎转载和引用,但请在明显处保留原文链接和原作者信息!
本博客内容多为个人工作与学习的记录,少数内容来自于网络并略有修改,已尽力标明原文链接和转载说明。如有冒犯,即刻删除!
以所舍,求所得,有所获,方所成。