srcmini本文概述
时间简史
为了了解DevOps, 我们必须回到过去, 那时程序员什么也没有。
正如道教我们的：
旧的程序员是神秘而深刻的。我们无法理解他们的想法, 因此我们要做的只是描述他们的外表：
- 意识到, 就像一只狐狸越过水面
- 机警, 像战场上的将军
- 善良, 就像女主人问候客人
- 简单, 就像未雕刻的木头块一样
- 不透明, 就像黑暗洞穴中的黑池
程序员诞生了机器语言。机器语言催生了汇编器。汇编器催生了编译器。现在有成千上万种语言。每种语言都有其目的, 但是谦虚。每种语言都表示软件的阴阳。每种语言在软件中都有其位置。
当时, 软件开发办公室通常被称为实验室, 程序员是科学家。为了创建一个好的应用程序, 程序员必须完全理解该应用程序正在解决的问题。他们必须知道该应用程序将在哪里使用以及将在哪种系统上运行。从本质上讲, 程序员从规范到开发到部署和支持都对他们的应用程序一无所知。
然后人性开始, 我们开始要求更多。更快的速度, 更多的功能, 更多的用户, 更多的功能。
作为谦虚, 谦逊和和平的动物, 程序员几乎没有机会生存于这样的有需求的用户群体中, 他们总是要求更多。获胜的最好机会是开始朝着不同的方向发展, 并创造种姓。很快, 程序员就消失了, 成为了开发人员, 软件工程师, 网络管理员, 数据库开发人员, Web开发人员, 系统架构师, 质量保证工程师等许多新人的前身。快速发展并适应来自外部世界的挑战已成为他们的DNA。新的种姓可能会在几周内进化。 Web开发人员变成了后端开发人员, 前端开发人员, PHP开发人员, Ruby开发人员, Angular开发人员……这简直是地狱。
很快, 他们都忘记了他们来自同一个程序员。一个简单和平的科学家, 只是想让世界变得更美好。他们开始互相打架, 声称每个人都是”程序员”的真正后代, 而且他们的血统比其他人纯正。
随着时间的流逝, 他们将互动减少到最低限度, 仅在确实需要时才互相交谈。他们停止庆祝远方家庭成员的成功, 最终甚至不时停止发送明信片。
如果只检查自己的感受, 他们会发现程序员的火花在他们的心中, 等待发光并为银河带来和平。
在征服世界的自私自利的竞赛中, 程序员的后代忘记了工作的真正目的-为客户解决问题。客户开始感到这种行为的痛苦, 因为项目被推迟, 太昂贵甚至失败。
每隔一段时间, 一颗明亮的星星就会闪耀, 有人会得到启发, 试图在后代之间实现和平。他们想出了瀑布。这是一个绝妙的主意, 因为它利用了这样的事实, 即不同组的开发人员仅在必要时进行通信。当一个小组完成了自己的工作后, 便与下一个小组进行了沟通, 以将工作发送到整个过程, 而再也没有回头。
这工作了一段时间, 但是像往常一样, 人类(客户)再次想要更多。他们希望在软件开发的整个过程中更加积极地参与, 多发表意见, 甚至在为时已晚时要求进行更改。
软件项目很容易失败, 以至于被接受为行业标准。统计数据表明, 超过50％的项目失败了, 而且似乎无可奈何(ZDNet, CNet)
每一代人都有一些胸襟开阔的人, 他们知道所有这些开发人员组都必须找到一种合作, 沟通和灵活的方法, 以确保他们的客户将获得最佳的解决方案。伟大的约翰·冯·诺伊曼(John Von Neumann)的同事们早在1957年就已经尝试过这些方法。但是, 我们不得不等到2001年初才开始这场革命, 当时一堆肮脏的东西创造了一个敏捷宣言。
敏捷宣言基于以下十二项原则：
- 通过尽早连续交付有价值的软件来使客户满意
- 即使在后期开发中也欢迎不断变化的需求
- 工作软件经常交付(数周而不是数月)
- 商界人士与开发人员之间的紧密日常合作
- 项目是围绕积极进取的个人建立的, 应该值得信任
- 面对面的对话是最好的交流方式(同一地点)
- 工作软件是进度的主要衡量标准
- 可持续发展, 能够保持稳定的步伐
- 持续关注技术卓越和良好的设计
- 简洁性(最大化未完成工作量的艺术)至关重要
- 自组织团队
- 定期适应不断变化的情况
敏捷宣言是将和平带入银河和恢复力量平衡的第一步。很长时间以来, 第一次在软件开发过程中将所有利益相关者联系起来是基于文化和”人”的方式, 以及基于程序和机械化的方式。人们开始互相交谈, 定期开会, 并始终交换意见和评论。他们意识到他们之间有很多共同点, 他们认为客户已经成为团队的一员, 而不仅仅是一些期望赚钱而不问任何问题的外部因素。
仍有许多障碍需要克服, 但未来似乎比以往更加光明。敏捷意味着开放, 愿意适应不断的变化。但是, 由于变化太多, 很难始终专注于最终目标和交付。这就是精益软件开发实现的方式。
由于迷恋LSD(双关语), 并有被放逐和流放的风险, 一些后代在种姓和软件行业之外寻求解决方案。他们在一家主要汽车制造商的作品中找到了救赎。丰田生产系统的简单性令人惊叹, 而且显而易见, 其精益生产可以轻松地应用于软件开发。
精益有7条原则：
- 消除浪费
- 建立质量
- 创造知识(扩大学习)
- 推迟承诺(尽早决定)
- 尽快交付
- 尊重人(赋予团队权力)
- 优化整体
除了敏捷之外, 精益原则还支持了心态和对做正确事的关注, 同时在整个过程中保持灵活性。
一旦敏捷开发和精益软件被软件开发团队采用, 仅需再采取一步, 即可将整套原则应用于IT整体-最终使我们进入了DevOps！
输入DevOps-三车道高速公路
软件开发团队的传统观点包括业务分析师, 系统架构师, 前端开发人员, 后端开发人员, 测试人员, 等等。优化软件开发流程(包括敏捷和精益原则)主要集中在这些方面。一旦应用程序”可以投入生产”, 就将其发送给”运营”部门, 包括系统工程师, 发布工程师, DBA, 网络工程师, 安全专业人员等。消除Dev和Ops之间的障碍是DevOps的主要推动力。
DevOps是对整个IT价值流实施精益原则的结果。 IT价值流将开发人员的所有”远方亲戚”结合在一起, 将开发工作扩展到生产中。
Gene Kim给出了DevOps解决方案的最好解释, 如果你还没有阅读The Phoenix Project, 建议你花些时间来做。
你不应该雇用DevOps工程师, DevOps也不应该是IT中的新部门。 DevOps是一种文化, 思维方式, 是IT整体的一部分。没有任何工具可以使你的IT成为DevOps组织, 没有任何自动化水平可以使你的团队为客户提供最大价值。
DevOps通常被称为三种方式的方法, 但我将它们视为同一条高速公路的三个车道。你从第一个车道开始, 然后加速并切换到第二车道, 最后在第三条车道超速行驶。
-
第一泳道-系统的整体性能是主要重点, 强调系统的任何单个元素的性能
-
泳道二-确保上游有一个恒定的反馈回路, 并且不被忽略
-
泳道三-培养实验, 不断改进和快速失败
第一车道-加快速度
理解整个系统的重要性并适当地确定工作项目的优先级是IT组织在采用DevOps原理时必须学习的第一件事。 IT价值流中的任何人都不允许创建瓶颈并减少工作流程。
确保流程中不间断的工作是流程中每个人的最终目标。无论个人或团队的角色是什么, 他们都必须寻求对系统的深刻理解。采用这种思维方式会对质量产生直接影响, 因为缺陷不会导致瓶颈, 因此永远不会将其发送到下游。
确保工作不会停滞还不够。一个生产性组织应该始终寻求增加流量。有许多方法可以增加流量。你可以在”约束理论”, ” 6西格玛”, “精益”或”丰田生产系统”中找到解决方案。随意选择其中任何一个, 提出自己的想法, 或将它们组合在一起。
如果你是系统架构师, DBA, QA或网络管理员, DevOps原则并不关心你属于哪个团队。相同的规则适用于每个人, 并且每个人都应遵循两个简单的原则：
- 保持系统流量不间断
- 随时增加和优化工作流程
第二车道-加速
不间断的系统流是单向的, 并且有望从开发到运营。在理想的世界中, 这意味着可以快速创建高质量的软件, 然后将其部署到生产中并为客户创造价值。
但是, DevOps并非乌托邦, 如果可以单向传递, 那么瀑布方法就足够了。评估可交付成果并沟通流程对于确保质量非常重要。必须实现的第一个”上游”通信渠道是Ops to Dev。
给自己五岁以下的孩子很容易, 但是要求反馈并提供反馈是查看真实情况的方法。至关重要的是, 下游的每一个小步骤都必须立即得到上游的确认。
如何建立反馈循环都无关紧要。你可以邀请开发人员参加支持团队会议, 或邀请网络管理员进行每周冲刺计划。只要你的反馈意见到位, 评论得到处理并得到处理, 你的组织就会加快DevOps高速公路的运行。
第三车道-经线10
DevOps快速通道不适合弱智人士。为了快速进入DevOps, 你的组织必须足够成熟。这就是冒险和从失败中学习, 不断地进行试验, 并接受重复和练习是精通技巧的前提。你经常会听到Kata一词, 这是有原因的。不断的训练和重复导致精通, 因为它使复杂的动作成为常规。
但是在开始组合动作之前, 必须先掌握每个步骤。
“适合硕士的不适合新手。在超越结构之前, 你必须了解道。”
DevOps Third Way / Fast Lane包括每天分配时间进行连续实验, 不断奖励团队承担风险, 将错误引入系统以提高弹性。
为了确保组织在实施此类措施时不会崩溃, 你必须在所有团队之间创建频繁的反馈循环, 同时确保清除所有瓶颈并且系统流程不中断。
实施这些措施可使你的组织始终保持警惕, 并能够快速有效地应对挑战。
摘要-DevOps组织清单
这是一个清单, 可用于验证DevOps如何为IT组织提供支持。请随意评论文章并添加你自己的观点。
- 开发团队和运营团队之间没有隔离墙。两者都是同一过程的一部分
- 从一个团队转移到另一个团队的工作总是经过验证并且质量最高
- 没有工作的”堆积”, 所有瓶颈都得到了解决
- 开发团队没有将”操作时间”用于其活动, 因为部署和维护是同一时间范围的一部分
- 开发团队不会在周五的下午5点交付部署代码, 而让运营人员在周末清理工作
- 开发环境是标准化的, 并且操作可以轻松地将其复制并扩展到生产中
- 开发团队可以根据需要提供新版本, 并且操作可以轻松地将其部署到生产中
- 所有团队之间都有明确的沟通渠道
- 所有团队成员都有时间进行实验并致力于系统的改进
- 定期引入(或模拟)缺陷并在系统中进行处理。将从每个实验中学到的经验教训记录下来, 并与所有相关人员分享。事件处理是例行程序, 通常以已知方式处理
总结
使用Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS等现代DevOps工具并不意味着你正在使用DevOps原理。 DevOps是一种思维方式。我们都是同一个过程的一部分, 我们共享相同的时间并共同创造价值。参与软件交付过程的每个人都可以加快或减慢整个系统。在开发过程中创建的错误会导致系统崩溃, 以及错误的防火墙配置。
所有人员都是DevOps的一部分, 一旦你的组织了解了这一点, 可以帮助你管理它的工具和技术堆栈就会神奇地出现。
相关：弥合差距：DevOps沟通的重要性
评论前必须登录！
注册