什么是DevOps？
在早期，解决方案与正确使用技术有关。关键是技术，解决方案是技术，预期的业务和为技术付费的业务。时代变了。好吧，至少对于那些注意到我们的人而言。今天，技术几乎不再是一个重大问题。从技术上讲，我们拥有一个不太复杂的世界。多年来，我们已经了解到，技术基本上是处理，内存，网络和存储的一种安排。我们已经通过使用虚拟化掌握了利用率。我们知道水平缩放比垂直缩放“更好”，并且我们可以在还包含软件解决方案的融合和超融合产品中更轻松地交付PMNS。我们已使许多关键活动实现了自动化，以减少时间和成本。
DevOps-通过帮助我们成为Service Broker，而不是服务器管理员或网络工程师，Cloud范式应运而生，并使生活变得更轻松。对客户而言，我们现在是服务经纪人；好吧，我们应该。鉴于应用程序和服务（解决方案）是从“服务目录”中交付的，因此我们应该缩短采购周期。尽管在公共云部署模型和软件即服务（SaaS）交付模型中可能确实如此，但是在私有云采购方面，我们似乎仍然停留在过去，并遭受不必要的延迟。即使越来越多的企业采用了公有云服务，将服务器，应用程序和服务“转移”到那里的活动仍然很艰难。
尽管进行了所有这些更改和学习，但是解决方案的设计和实现仍然是一项艰巨的工作，并且会产生大量的文档（有些需要，有些毫无意义），无休止的Gant图表和无休止的会议，试图将解决方案落实到位并交付使用。为什么是这样？
应用开发与交付
应用程序开发人员习惯于生活在自己的世界中。在某种程度上还是如此。应用开发公司通常没有网络工程师，技术架构师和存储中小型企业来参加清晨的讨论。应用程序是独立开发的，并且与需要创建以托管，提供资源和支持应用程序的技术解决方案分开。
在大多数情况下，出于两个原因之一开发应用程序。为外部客户提供解决方案或为可从中获利的业务提供应用程序。例如，一家公司需要支付薪水。为此，它需要一个应用程序，该应用程序可以根据收入服务“聘用规则”中列出的法律框架，支付薪水，计算税金和养老金信息并将数据输入数据库，然后打印薪水单。应用程序开发公司将迎接这一挑战，并通过一系列迭代，它将交付一个满足所有客户和法律要求的应用程序。对于想从应用程序中赚钱的企业，情况与外部客户非常相似。财务上的差异在于，企业必须证明让开发人员聘请员工创建应用程序的成本是合理的。该成本是根据最终将应用程序作为企业服务部署而获得的收入预测中设置的。
在这两个示例中，都有一些常数可能会使您难以接受。技术解决方案受人员，流程和政治影响的方式相同，因此应用程序开发也受孤立主义实践的影响。
为什么是这样？
在从数据中心基础架构到应用程序再到云的所有IT中，有一个问题会影响项目的顺利，联合运行，这就是“活动孤岛”。
筒仓长期以来一直是IT的黑标。我们已经习惯了孤岛经营，因此我们不怀疑这种安排是否富有成效和成本效益。实际上，即使到现在，大多数IT组织仍在使用孤岛运作。孤立地解决和开发。
解决方案设计和应用程序开发将精益和敏捷的出现视为一种真正有效的运营方式，但是仍然存在孤岛。公司运营敏捷，但保持了孤岛式的做事方式。考虑到这一点，很奇怪。敏捷意味着灵活且能够无创伤地进行改变。筒仓是一个高边的“坑”，很难改变。因此，从本质上讲，敏捷和筒仓共同努力，使变革变得困难。仍然如此。
筒仓
这是一个基于筒仓的传统IT环境的实际示例，在该环境中将开发和部署应用程序。在某些公司中，该过程可能会略有不同，职位可能不同，但是，这是我在多家大型IT公司工作的经验，并且可以将其识别为相当普遍的程序。
应用程序开发人员根据概念或请求创建应用程序。要求技术服务（TS）架构师为应用程序基础结构创建高级设计（HLD）。TS建筑师将HLD传递给项目建筑师以审查设计。项目架构师将最终的HLD交还给TS架构师。TS架构师向应用程序开发人员解释了设计，并涵盖了可能危害应用程序的所有项目。通常这是与其他专家隔离的。该HLD已被批准购买他人或其他人，项目建筑师着手进行尽职调查活动，然后为应用程序基础结构创建底层设计（LLD或Build Doc）。项目架构师必须访问各种主题专家（SME），以进行计算，网络，存储和灾难恢复（DR），以查找LLD中需要具备哪些技术和要求。有关协议，路由，安全性和防火墙规则的详细信息可能很复杂，如果不仔细计划，可能会对应用程序产生负面影响。为了实现此权利，需要咨询业务影响分析专家，以确保可以解决或缓解安全和合规性问题（如果存在）。大多数应用程序已部署到虚拟基础架构，这需要虚拟化专家的参与以帮助配置和自动化技术。总而言之，项目架构师必须咨询许多不同的技术/专家团队。在此活动过程中，架构师必须不断地返回给应用程序开发人员，以检查为基础结构计划的内容是否不会“损害”应用程序设计并在部署时使应用程序失效。最后，需要使用服务包装来支持应用程序并满足服务水平协议（SLA）中的非功能性要求。很可能会有二十个人参与此过程。我没有包括测试和开发，因为这通常要等到主流程和用户接受测试（UAT）结束时才能进行。有时有一个单独的团队来处理这一部分，有时是由Operations来执行。应用程序设计还包括提供中间件和数据库层的依赖项层。包括这些服务时，可能需要更多的人参与。真实的是，每个SME都是筒仓的一部分。该项目必须咨询所有这些孤岛。有些有用，有些没有，并且有很多原因为什么没有！可以回答所有问题和建议的解决方案。
所有的孤岛和所有相关人员使整个项目缓慢而昂贵。类比是蛇和梯子的游戏。
开发运维
尽管上面的示例有些粗糙，但是它可以公平地评估端到端的应用程序开发。行业中的每个人都知道这是“正常”的状况，并接受它并不完美。DevOps已经开始出现，作为对传统筒仓方法的答案。DevOps尝试删除孤岛，并以协作和包容性活动（即项目）替换它们。应用程序开发和解决方案设计受益于DevOps原理。
删除筒仓需要做什么：
改变工作文化
删除团队之间的墙（然后删除筒仓）
按键：
沟通，协作，整合和信息共享
说起来容易，做起来很难。
大多数中小型企业喜欢将自己的信息保密。但并非如此，但对许多人而言并非如此。它是多年来发展起来的传统文化的一部分。工作实践使变革变得困难。变更管理是任何公司都可以从事的最具挑战性的任务之一。抵抗将具有韧性，因为人们放弃某些东西以获取某些东西很重要。弄清楚什么是必须的。人们会改变他们的态度和行为，但是，您必须给他们提供充分的理由。我发现，为中小企业举办多学科研讨会已被证明是鼓励信息共享和打破那些“坑壁”的有效方法。
向团队解释什么是DevOps，以及应该实现什么是教育过程的第一部分。第二是需要做的事情。
陈述具体的，可衡量的目标：
实施“扁平化”的组织结构。如果我们主张横向扩展，为什么不横向组织呢？
每个App-Dev或Solution-Dev都是一个项目，并且团队是跨学科的端到端
进行持续的信息交流和审查
确保每个人都注册DevOps并了解范例
什么是DevOps
就像云范式一样，它只是做事的另一种方式。像Cloud一样，根据您当时与谁说话，它具有不同的定义。
Wikipedia指出： 因为DevOps是开发和运营之间的文化转变和协作，所以没有单一的DevOps工具，而是由多个工具组成的集合或“工具链”。通常，DevOps工具可归为一类或多类，这反映了软件开发和交付过程。
我不认为这就是DevOps的全部。可以推断出DevOps仅与应用程序开发和操作有关。我不认为。我相信DevOps是一个范式，并且像其他IT“标准”和范式一样，它与所有IT都相关，而不仅仅是应用程序。通过消除链中每个实践之间的划分，并从一开始就让所有关键参与者参与进来，作为一个包容和协作的团队的一部分，应用程序开发和解决方案设计的周期变成了一个连续的过程，无需转移到咨询每个所需的专家。没有人需要将文件扔在墙上给下一个工作人员。每个文档都是在协作过程中编写的，这必须使文档更加相关和强大。想象一下，从概念到部署，项目团队始终在同一个房间里，并且每个专家总是可以对项目的每个步骤进行评论和添加。这比传统方法要好很多天，因为它可能需要几天的时间才能回答一个简单的问题，甚至找到合适的人去问。
口头禅是：开发，测试，部署，监视，反馈等。这听起来是面向应用程序的。实际上，它可以应用于任何IT解决方案的开发。像ITIL，TOGAF和“七层参考模型”一样，它可以应用于从开发到支持服务的所有IT活动。DevOps使我们从头到尾都在同一页面上。
不要让您的公司孤立地实现DevOps，而只能作为应用程序开发的框架。为此，将创建另一个筒仓。将它用于每个项目，并作为所有团队的默认文化，无论他们是开发人员，工程师，架构师还是运营人员。最后，不要使其复杂化。DevOps不需要深入和深刻的定义，也不需要关于它是什么以及如何实现它的冗长乏味的对话。去做就对了。
题库