为了理解 Dev运维，我们必须回到那个只有程序员的年代.
随着 道 教导我们:
过去的程序员是神秘而深刻的. 我们不能了解他们的思想，所以我们只能描述他们的外表;
程序员创造了机器语言. 机器语言产生了汇编程序. 汇编程序产生编译程序. 现在有成千上万种语言. 每种语言都有它的目的，不管它有多卑微. 每种语言都表达了软件的阴和阳. 每种语言在软件中都有自己的位置.
当时，软件开发办公室大多被称为实验室，程序员是科学家. 为了创建一个好的应用程序, 程序员必须完全理解应用程序要解决的问题. 他们必须知道应用程序将在哪里使用，以及什么样的系统将运行它. 在本质上, 程序员从规范中了解应用程序的一切, 通过发展, 部署和支持.
然后人性开始发挥作用，我们开始要求更多. 更快的速度，更多的功能，更多的用户，更多的一切.
谦虚, 卑微的, 和平的生物, 程序员几乎没有机会在这种总是要求更多的需求的用户爆发中生存下来. 获胜的最好机会是开始向不同的方向进化，并创造种姓. 很快, 作为开发人员的先祖，程序员已经灭绝了, 软件工程师, 网络管理员, 数据库开发人员, web开发人员, 系统架构师, QA工程师，以及更多. 快速进化和适应外部世界的挑战成为他们DNA的一部分. 新的种姓制度可能在几周内形成. Web开发人员变成了后端开发人员, 前端开发人员, PHP开发人员, Ruby开发人员, Angular开发者们……都要完蛋了.
很快，他们都忘记了他们来自同一个父亲，一个程序员. 一个单纯而平和的科学家只想让世界变得更美好. 他们开始互相争斗, 声称他们每个人都是“程序员”的真正后代，他们的血统比其他人更纯净.
随着时间流逝, 他们把彼此的互动减少到最低限度，只有在必要的时候才会说话. 他们不再庆祝远房亲戚的成功, 最后甚至不再隔一段时间寄明信片了.
如果他们只搜索自己的感受, 他们会发现程序员的火花就在他们心中, 等待闪耀，为银河系带来和平.
在他们自私和以自我为中心的种族中征服世界, 程序员的后代忘记了他们工作的真正目的——为客户解决问题. 当项目被推迟时，客户开始感受到这种行为的痛苦, 太贵了, 甚至失败.
时不时地, 一颗明亮的星星会闪耀，有人会得到灵感，试图在后裔之间实现和平. 他们想出了《欧博体育app下载》. 这是个绝妙的主意, 因为它利用了这样一个事实，即不同的开发小组只在必要时进行沟通. 当一组完成了他们的工作, 它与下一个小组沟通，将工作发送到流程中，并且从不回头看它.
这工作了一段时间，但像往常一样，人类(客户端)想要更多. 他们希望更积极地参与到软件开发的整个过程中, 多给他们一些意见, 要求改变，即使已经太迟了.
软件项目变得如此容易失败，以至于它被接受为一个行业标准. 统计数据显示，超过50%的项目失败了, 似乎对此已经无能为力了ZDNet, CNet)
每一代人都有一些思想开放的人，他们知道所有这些开发团队必须找到一种合作的方式, 沟通, 灵活地保证他们的客户能得到最好的解决方案. 早在1957年就有这些企图的痕迹, 伟大的约翰·冯·诺伊曼的同事们. 然而，我们不得不等到2001年初才开始革命, 当时有一群人写了一份敏捷宣言.
敏捷宣言基于12条原则:
敏捷宣言是为银河系带来和平和恢复原力平衡的第一步. 这么长时间以来第一次, 连接软件开发过程中的所有涉众是基于文化和“人”的方式, 就像程序化和机械化的方式一样. 人们开始互相交谈, 定期见面, 并随时交换意见和评论. 他们意识到他们之间的共同点比他们想象的要多得多, 客户也成为了团队的一部分, 而不仅仅是一些外界因素寄钱过来，不问任何问题.
虽然仍有一些障碍需要克服，但未来似乎比以往任何时候都更加光明. 敏捷意味着开放并愿意适应不断的变化. 然而, 有太多的变化, 专注于最终目标和交付是很困难的. 这就是精益软件开发的由来.
迷上了 迷幻药 (双关语)冒着被放逐的危险, 一些人的后代在他们的种姓和软件行业之外寻找解决方案. 他们在一家大型汽车制造商的工作中得到了拯救. 丰田生产体系 它的简单令人惊叹，而且很明显，它的 精益生产 可以很容易地应用到软件开发中吗.
精益有7个原则:
添加在敏捷之上, 精益原则支持心态和专注于做正确的事情, 同时在整个过程中保持灵活.
曾经的敏捷和精益 被软件开发团队采用了吗, 我们只需要再多走一步，就可以将整套原则作为一个整体应用到it中——这最终将我们带到了Dev运维!
软件开发团队的老派观点包括业务分析师, 系统架构师, 前端开发人员, 后端开发人员, 测试人员, 等等......。. 优化软件开发过程, 包括敏捷和精益原则, 主要关注这些吗. 一旦应用程序“准备好生产”, 它被送到了运营部，包括系统工程师, 发布工程师, dba, 网络工程师, 安全专家, 等. 移开之间的长城 Dev 和 运维 的主要驱动力是什么 Dev运维.
Dev运维是在整个IT价值流中实现精益原则的结果. IT价值流将开发扩展到生产, 结合了所有从最初的程序员传下来的“远亲”.
最好的解释是 Dev运维的解决方案 是由 基因金，如果你还没读过 凤凰计划 我建议你花点时间去做.
你不应该雇佣Dev运维工程师，Dev运维也不应该成为你IT中的一个新部门. Dev运维是一种文化、一种心态，它是整个it的一部分. 没有什么工具可以让你的IT成为一个 Dev运维组织任何程度的自动化都不能使您的团队为您的客户提供最大的价值.
Dev运维通常被称为三种方法的方法, 但我把它们看成是同一条高速公路上的三条车道. 你从第一车道开始, 然后你加速，换到第二车道, 最后你在第三条车道超速行驶.
通道一——系统的整体性能是主要的焦点，它比系统的任何单个元素的性能都要强调
通道二——确保上游有一个持续的反馈循环，而不是被忽略
车道三:培育实验，不断改进，快速失败
理解整个系统的重要性, 正确地确定工作项的优先级是IT组织在采用Dev运维原则时必须学习的第一件事. 不允许IT价值流中的任何人制造瓶颈并减少工作流程.
确保不间断的工作流程是过程中每个人的最终目标. 无论一个人或一个团队的角色是什么，他们都必须寻求实现 对系统有深刻的理解. 采用这种思维方式对质量有直接的影响, 由于缺陷永远不会被发送到流程中，因为它们会导致瓶颈.
确保工作不拖延是不够的. 一个高效的组织应该总是寻求增加流量. 有许多方法可以增加流量. 你可以在 约束理论, 六西格玛精益生产或丰田生产系统. 你可以随意选择其中的任何一个，自己想出来，或者把它们结合起来.
Dev运维原则并不关心你属于哪个团队, 如果您是系统架构师, DBA, QA, 或者网络管理员. 同样的规则适用于每个人，每个人都应该遵循两个简单的原则:
不间断的系统流程是单向的, 预计它将从开发阶段进入运营阶段. 在理想情况下，这意味着软件的创建速度快，质量高, 部署到生产环境, 并为客户提供价值.
然而, Dev运维不是乌托邦, 如果单向输送是可能的，瀑布法就足够了. 评估可交付成果和沟通流程对于保证质量非常重要. 必须实现的第一个“上游”通信通道是运维到Dev.
跟自己击掌很容易, 但寻求反馈并给予反馈是看到真实情况的方式. 这是必要的，每一个小的步骤下游跟着一个即时的上游确认.
你如何建立反馈循环并不重要. 您可以邀请开发人员加入支持团队会议, 或者让网络管理员参与每周冲刺计划. 只要你的反馈到位, 评论被收集和处理, 你的组织正在加速发展Dev运维.
Dev运维的快车道不是为弱者准备的. 要走上Dev运维的快车道，你的组织必须足够成熟. 这一切都是关于冒险和从失败中学习, 不断地尝试, 接受重复和练习是精通的先决条件. 你会经常听到这个词 型这是有原因的. 持续的训练和重复导致精通，因为它使复杂的动作成为常规.
但在你开始组合动作之前，你必须先掌握每一步.
“适合大师的东西，不一定适合新手. 在超越结构之前，你必须了解道.”
Dev运维第三条道路/快车道包括每天分配时间进行持续的实验, 不断奖励冒险的团队, 并在系统中引入故障以增加弹性.
为了确保您的组织在实施这些措施时不会崩溃, 您必须在所有团队之间建立频繁的反馈循环, 同时确保所有瓶颈都是明确的，系统流是不间断的.
实施这些措施可以使您的组织时刻保持警觉，并能够快速有效地应对挑战.
这里有一个清单，您可以使用它来验证如何 Dev运维启用 你的IT组织是. 请随意评论这篇文章并添加你自己的观点.
使用现代 Dev运维的工具 比如Chef、码头工人、Ansible、封隔器、对流层、领事、詹金斯、SonarQube、AWS等. 并不意味着你在应用Dev运维原则. Dev运维是一种思维方式. 我们都是同一个过程的一部分，我们分享同样的时间，共同创造价值. 参与软件交付过程的每个人都可以加速或减慢整个系统的速度. 在开发过程中产生的错误可能会导致系统崩溃, 以及错误的防火墙配置.
所有人都是Dev运维的一部分, 一旦你的组织明白了这一点, 帮助你管理它的工具和技术堆栈将神奇地出现.
世界级的文章，每周发一次.
世界级的文章，每周发一次.
作者都是各自领域经过审查的专家，并撰写他们有经验的主题. 我们所有的内容都经过同行评审，并由同一领域的Toptal专家验证.