《欧博体育app下载》。

为了理解 Dev运维，我们必须回到那个只有程序员的年代.

随着 道 教导我们:

The programmers of old were mysterious 和 profound. 我们不能了解他们的思想，所以我们只能描述他们的外表;

• Aware, like a fox crossing the water
• Alert, like a general on the battlefield
• Kind, like a hostess greeting her guests
• Simple, like uncarved blocks of wood
• Opaque, like black pools in darkened caves

程序员 gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are thous和s of languages. Each language has its purpose, however 卑微的. Each language expresses the Yin 和 Yang of software. Each language has its place within the software.

当时，软件开发办公室大多被称为实验室，程序员是科学家. In order to create a good application, 程序员必须完全理解应用程序要解决的问题. 他们必须知道应用程序将在哪里使用，以及什么样的系统将运行它. 在本质上, 程序员从规范中了解应用程序的一切, 通过发展, 部署和支持.

然后人性开始发挥作用，我们开始要求更多. More speed, more features, more users, more everything.

谦虚, 卑微的, 和平的生物, 程序员几乎没有机会在这种总是要求更多的需求的用户爆发中生存下来. 获胜的最好机会是开始向不同的方向进化，并创造种姓. 很快, 作为开发人员的先祖，程序员已经灭绝了, 软件工程师, 网络管理员, 数据库开发人员, web开发人员, 系统架构师, QA工程师，以及更多. 快速进化和适应外部世界的挑战成为他们DNA的一部分. New caste could evolve in a matter of weeks. Web developers became 后端开发人员, 前端开发人员, PHP开发人员, Ruby开发人员, Angular developers … it was all going to hell.

很快，他们都忘记了他们来自同一个父亲，一个程序员. 一个单纯而平和的科学家只想让世界变得更美好. 他们开始互相争斗, 声称他们每个人都是“程序员”的真正后代，他们的血统比其他人更纯净.

随着时间流逝, 他们把彼此的互动减少到最低限度，只有在必要的时候才会说话. 他们不再庆祝远房亲戚的成功, 最后甚至不再隔一段时间寄明信片了.

If they only searched their feelings, 他们会发现程序员的火花就在他们心中, waiting to shine 和 bring peace to the galaxy.

In their selfish 和 egocentric race to conquer the world, 程序员的后代忘记了他们工作的真正目的——为客户解决问题. 当项目被推迟时，客户开始感受到这种行为的痛苦, 太贵了, 甚至失败.

时不时地, 一颗明亮的星星会闪耀，有人会得到灵感，试图在后裔之间实现和平. 他们想出了《欧博体育app下载》. 这是个绝妙的主意, 因为它利用了这样一个事实，即不同的开发小组只在必要时进行沟通. When one group finished their part of the job, 它与下一个小组沟通，将工作发送到流程中，并且从不回头看它.

这工作了一段时间，但像往常一样，人类(客户端)想要更多. 他们希望更积极地参与到软件开发的整个过程中, 多给他们一些意见, 和 ask for changes even when it was too late.

软件项目变得如此容易失败，以至于它被接受为一个行业标准. Statistics showed that over 50% of projects were failing, 似乎对此已经无能为力了ZDNet, CNet)

每一代人都有一些思想开放的人，他们知道所有这些开发团队必须找到一种合作的方式, 沟通, 灵活地保证他们的客户能得到最好的解决方案. There are traces of these attempts even as early as 1957, by colleagues of the great John Von Neumann. 然而，我们不得不等到2001年初才开始革命, when a dirty dozen created an 敏捷 Manifesto.

The 敏捷 Manifesto is based on twelve principles:

1. 通过早期和持续交付有价值的软件来实现客户满意度
2. Welcome changing requirements, even in late development
3. 经常交付工作软件(几周而不是几个月)
4. 业务人员和开发人员之间密切的日常合作
5. 项目是围绕有动力的个人建立的，他们应该被信任
6. 面对面的交谈是最好的交流形式(共同定位)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. 持续关注技术卓越和良好的设计
10. 简化——最大化未完成工作量的艺术——是必不可少的
11. 自组织的团队
12. Regular adaptation to changing circumstance

敏捷宣言是为银河系带来和平和恢复原力平衡的第一步. For the first time in a very long time, 连接软件开发过程中的所有涉众是基于文化和“人”的方式, as much as on procedural 和 mechanized manner. 人 started to talk to each other, 定期见面, 和 exchange ideas 和 comments all the time. 他们意识到他们之间的共同点比他们想象的要多得多, 和 clients became part of the team, 而不仅仅是一些外界因素寄钱过来，不问任何问题.

虽然仍有一些障碍需要克服，但未来似乎比以往任何时候都更加光明. 敏捷意味着开放并愿意适应不断的变化. 然而, 有太多的变化, 专注于最终目标和交付是很困难的. And that is how 精益 Software Development came to life.

迷上了 迷幻药 (pun intended) 和 risking to be exiled 和 outcast, 一些人的后代在他们的种姓和软件行业之外寻找解决方案. 他们在一家大型汽车制造商的工作中得到了拯救. 丰田生产体系 它的简单令人惊叹，而且很明显，它的 精益生产 can be easily applied to software development.

精益有7个原则:

1. 消除浪费
2. 建立品质
3. Create Knowledge (Amplify learning)
4. Defer Commitment (Decide as late as possible)
5. 尽可能快地交付
6. 尊重他人(授权给团队)
7. 整体优化

添加在敏捷之上, 精益原则支持心态和专注于做正确的事情, while being flexible during the whole process.

曾经的敏捷和精益 were adopted by software development teams, 我们只需要再多走一步，就可以将整套原则作为一个整体应用到it中——这最终将我们带到了Dev运维!

进入Dev运维 -三车道高速公路

软件开发团队的老派观点包括业务分析师, 系统架构师, 前端开发人员, 后端开发人员, 测试人员, 等等......。. Optimizing software development process, including agile 和 lean principles, 主要关注这些吗. Once the application was “production ready”, 它被送到了运营部，包括系统工程师, 发布工程师, dba, 网络工程师, 安全专家, 等. 移开之间的长城 Dev 和 运维 的主要驱动力是什么 Dev运维.

Dev运维是在整个IT价值流中实现精益原则的结果. IT value stream extends development into production, 结合了所有从最初的程序员传下来的“远亲”.

最好的解释是 Dev运维的解决方案 是由 基因金，如果你还没读过 凤凰计划 I suggest you take some time 和 do it.

你不应该雇佣Dev运维工程师，Dev运维也不应该成为你IT中的一个新部门. Dev运维是一种文化、一种心态，它是整个it的一部分. There are no tools that will make your IT a Dev运维组织任何程度的自动化都不能使您的团队为您的客户提供最大的价值.

Dev运维 is usually referred as method of three ways, but I see them as three lanes of the same highway. 你从第一车道开始, then you speed up 和 switch to lane two, 和 eventually you are speeding by in the third lane.

• 通道一——系统的整体性能是主要的焦点，它比系统的任何单个元素的性能都要强调

• 通道二——确保上游有一个持续的反馈循环，而不是被忽略

• 车道三:培育实验，不断改进，快速失败

车道一-加快速度

Underst和ing the importance of the whole system, 正确地确定工作项的优先级是IT组织在采用Dev运维原则时必须学习的第一件事. 不允许IT价值流中的任何人制造瓶颈并减少工作流程.

确保不间断的工作流程是过程中每个人的最终目标. 无论一个人或一个团队的角色是什么，他们都必须寻求实现 profound underst和ing of the system. 采用这种思维方式对质量有直接的影响, 由于缺陷永远不会被发送到流程中，因为它们会导致瓶颈.

Making sure that work is not stalling is not enough. 一个高效的组织应该总是寻求增加流量. There are numerous methodologies to increase the flow. 你可以在 约束理论, 六西格玛, 精益, or 丰田生产体系. 你可以随意选择其中的任何一个，自己想出来，或者把它们结合起来.

Dev运维 principles do not care what team you belong to, 如果您是系统架构师, DBA, QA, 或者网络管理员. 同样的规则适用于每个人，每个人都应该遵循两个简单的原则:

• 保持系统流程不中断
• Increase 和 optimize workflow at all times

二车道，准备好

Uninterrupted system flow is one-directional, 和 it is expected to go from development to operations. 在理想情况下，这意味着软件的创建速度快，质量高, 部署到生产环境, 并为客户提供价值.

然而, Dev运维不是乌托邦, 如果单向输送是可能的，瀑布法就足够了. 评估可交付成果和沟通流程对于保证质量非常重要. 必须实现的第一个“上游”通信通道是运维到Dev.

Giving a high-five to yourself is easy, 但寻求反馈并给予反馈是看到真实情况的方式. 这是必要的，每一个小的步骤下游跟着一个即时的上游确认.

It does not matter how you establish the feedback loop. You can invite developers to join support team meetings, or bring in the network admin to weekly sprint planning. As long as your feedback is in place, 和 comments are picked-up 和 h和led, your organization is speeding down the Dev运维 highway.

3车道，曲速10

Dev运维 fast lane is not for weak minded. 要走上Dev运维的快车道，你的组织必须足够成熟. It is all about taking risks 和 learning from failure, 不断地尝试, 接受重复和练习是精通的先决条件. 你会经常听到这个词 型这是有原因的. 持续的训练和重复导致精通，因为它使复杂的动作成为常规.

但在你开始组合动作之前，你必须先掌握每一步.

“适合大师的东西，不一定适合新手. You must underst和 道 before transcending structure.”

Dev运维第三条道路/快车道包括每天分配时间进行持续的实验, constantly rewarding the team for taking risks, 并在系统中引入故障以增加弹性.

为了确保您的组织在实施这些措施时不会崩溃, you must create frequent feedback loops between all teams, 同时确保所有瓶颈都是明确的，系统流是不间断的.

实施这些措施可以使您的组织时刻保持警觉，并能够快速有效地应对挑战.

Summary - Dev运维组织 checklist

Here is a checklist that you can use to validate how Dev运维启用 你的IT组织是. 请随意评论这篇文章并添加你自己的观点.

• 开发团队和运维团队之间没有隔离墙. 两者都是同一过程的一部分
• 从一个团队发送到另一个团队的工作总是经过验证和高质量的
• 没有“堆积”的工作，所有的瓶颈都得到了处理
• 开发团队没有将运维时间用于其活动, 因为部署和维护是同一时间框的一部分
• 开发团队不会在周五下午5点交付部署代码, 让运营部门在周末清理他们的工作
• Development environments are st和ardized, 操作可以很容易地将它们复制并扩展到生产中
• 开发团队可以交付他们认为合适的新版本，操作人员可以轻松地将它们部署到生产环境中
• There are clear communication lines between all teams
• 所有的团队成员都有时间来试验和改进系统
• 在系统中定期引入(或模拟)和处理缺陷. 从每次实验中吸取的经验教训都被记录下来，并与所有相关人员分享. 事件处理是一个例行程序，并且大多以已知的方式处理

结论

使用现代 Dev运维的工具 比如Chef、码头工人、Ansible、封隔器、对流层、领事、詹金斯、SonarQube、AWS等. does not mean that you are applying Dev运维 principles. Dev运维是一种思维方式. 我们都是同一个过程的一部分，我们分享同样的时间，共同创造价值. 参与软件交付过程的每个人都可以加速或减慢整个系统的速度. 在开发过程中产生的错误可能会导致系统崩溃, as well as the wrong firewall configuration.

All of the people are part of Dev运维, 和 once your organization underst和s that, 帮助你管理它的工具和技术堆栈将神奇地出现.