您的位置： >>
DevOps 是一种极其成功的精益管理实践，面向包括软件在内的业务流程，这一点已得到广泛认可。然而，诸如价值流程图（value stream mapping）和流程管理等精益技术通常被应用于更多更容易控制的流业务流程，比如制造和物流。本文将 DevOps 作为一种以工件为中心的业务流程，将这些精益技术扩展到包括软件在内的流程。通过这种方法，我们将展示如何对 DevOps 进行增强和估量，从而帮助实现业务目标。
　　DevOps 是一种精益应用程序
　　DevOps 旨在更好地集成 IT 操作和软件开发，从而提高对业务更改的联合响应能力。这些业务更改可能包括对某个问题单做出响应或者提供业务所需的新服务。DevOps 旨在完成以下目标：
缩短某个更改请求变成可接受响应的时间。
减少实现更改服务而浪费的时间和精力。
在从操作到开发再到部署的整个阶段中实现更加流畅的请求。
平衡企业解决需求的能力。
　　这和采用精益计算原理（称为精益技术）的目的相同。可以将精益技术描述为一种思维方式和一组技术集合，它们可用于管理和改善端到端周期时间（或交货时间），并充分利用某个企业的能力来优化整个流程的资源流（库存）。Lord Kelvin 提供了一个人们所熟悉的短语 &测量就是为了发现&，通过测量来了解精益可视化技术（如 ，包含产品流测量）带来的影响。流测量包括对库存进行端到端（黑盒）和分步（白盒）测量，测量流程时间，以及成品花费在存货阶段（等待处理）的时间。
　　最近，IBM 进一步扩展了 DevOps 最初的定义范围，包括了以下原则：
DevOps 代表企业实现持续软件交付的能力，使企业能够抓住市场机遇并缩短客户反馈时间。
它跨生命周期并跨企业地扩展了精益和敏捷概念，在所有环节实现了更丰富的反馈周期。
在整个企业范围实现精益转换能够支持更高效的交付，持续的反馈则有助于更有效地确定工作方向。
采用 DevOps 帮助企业在实现交付速度和可靠的结果之间取得平衡。
　　从这一点来看，可以推断出以下结论：
DevOps 旨在精简扩展后的包括软件在内的生命周期，比如：
IT：从问题识别到成功解决。
实现持续工程：从嵌入式软件规范到成功的集成。
产品开发：从最初的理念到成功推向市场。
服务交付：从提出业务要求到令客户感到满意。
DevOps 就是将精益原则和实践应用到这些方面。
　　过去，精益原则一直应用于制造业、后台流程和物流业。这些流程具有更好的可预测性，与 DevOps 所支持的流程相比缺少变化。对软件（）和一般性知识工作（）应用精益原则并不是什么新鲜事物。本文对已有的实践做法进行了扩展，将 DevOps 作为一种以工件为中心的业务流程，这样就可以将精益实践和测量顺利应用到 DevOps 流程。
　　在应用精益实践和原则时，必须增强流测量以检测瓶颈和低效率事件，从而找到机会进行改进并采取措施。以工件为中心的一个关键优势是可以很容易地指定和增强流测量。
　　以下小节介绍了这种以工件为中心的观点以及为什么应用于 DevOps。您将了解到如何应用它以指定流测量。本文最后概括性介绍了两种关键使用模型：项目指导（program steering）和持续改进。
　　DevOps 是一种以工件为中心的流程
　　您可以通过两种方式呈现一个流程：
以操作为中心：将按照执行流程以最终创建产品所需的操作以及它们的顺序描述流程，可以通过流程图或
进行描述。
以工件为中心：用最终的产品和它们的生命周期描述流程。最终的产品被作为状态机对待，它们将进行状态转换。通过状态转换获得成品，以这种方式指定每一个流程步骤。
　　所有流程都会让最终的产品完成它们的生命周期。以工件为中心的观点将描述要做的工作，而以操作为中心的观点则会描述完成工作要做的步骤。例如，在定义一个软件开发流程时，以工件为中心的观点将会描述完成一个代码模型需要做些什么；比如必须减少代码、构建代码并成功通过系统集成测试。程序员需要完成从 &设计& 到 &创建& 代码模型的工作，而不是具体告诉他们要采取哪些步骤来完成从 &设计& 到 &创建& 的转换（打开一个 IDE，创建一个文件，编写代码，进行一次代码审查，运行单元测试，统计 bug 等等）。程序员（事实上包括所有知识工作者（knowledge workers））都讨厌被告知如何完成自己的工作。实际要做的步骤以及每个步骤所需付出的努力都是无法提前预知的。知识工作涉及太多变化因素，因此难以实际预测每个具体步骤。
　　精益技术通常应用于需要处理相同或非常类似的成品的流程，如制造业。事实上，这些流程的目标是最小化产品输出的差异变化。以操作为中心的观点很适合此类流程。如果您要生产某种灯泡，那么每个灯泡都是相同的，因此每个流程步骤都可以提前指定。如果要处理问题单或业务请求，由于每一个问题单或业务请求都是不同的，因此实际操作步骤也会因此不同。有时，工作人员需要查询日志，装入内核转储（kernel dump），努力重现问题，添加一个新的跟踪并运行新的测试脚本，亦或者什么都不需要做。因此，要对 DevOps 应用精益原理，您必须考虑到成品（工件）和流程的差异性，需要采取以工件为中心的观点。
　　对以工件为中心的流程采取价值流程图
　　其中一种重要精益转换技术就是价值流程图，如图 1 所示。在 （Rother，Shook，Womack，& Jones，1999 年）一书中，您可以了解价值流程图（VSM）在实现转换时的应用及其指标。您可以通过许多方式使用 VSM：
使用 VSM 帮助所有相关人员原样呈现成品流程。
使用流程测量找出在哪些位置浪费了时间和精力，并设置基准和目标。
使用流程内（in-process）测量来判断是否能够通过提高效率来打破瓶颈，比如实现自动化或消除无价值的行为，或增加处理能力。
利用这些信息确定一个具有更加流畅流程的潜在 VSM。
计划并实现必要的更改，从当前 VSM 迁移到目标 VSM。
持续进行改进。使用测量来监视流程并按计划做出调整。
　　图 1. 一个简单的价值流程图
　　图 1 是一个简单的价值流程图例子。它显示了流程步骤和每个步骤的时间。通常，每个流程步骤都关联了执行流程所需操作的详细描述。比如，用于制造流程的操作描述可能是以下步骤：
从库存中取出零件。
检查零件的毛边。
将部件放到钻床钩子中。
以 15 毫米为间隔，钻出洞 1 和 4。
更改为 22 毫米间隔。
钻出洞 2 和洞 3。
拆除零件。
使用钢丝网对洞进行抛光。
　　图 1 使用了以下符号：
最左侧的架状图标显示零件库存，零件将经历整个流程。
I 图标表示库存的零件数量。
虚线箭头为拉出箭头（pull arrow），表示步骤 1 首先由工人从库存中取出一些部件。
其他箭头为推送箭头（push arrow），表示完成一个步骤的员工将工作推进到下一步骤。
　　要对以工件为中心的流程应用价值流程图，首先要识别出流程工件。每个工件具有自己的生命周期，即工件从开始到完成需要经历一些不同的状态。
　　例如，一个简单的业务请求状态模型包括以下阶段：
　　关键点在于对于以工件为中心的工作，流程步骤涉及到状态转换的过程。
　　具体地讲，价值流程图中的流程块表示将工件从一个状态推进到下一个状态所做的工作。对于这种情况，流程步骤与操作描述并没有关联，而是与完成状态转换的标准规范有关。
　　采用这种方法有两个优势：
它描述了要做的工作，而不是如何完成工作。
它真正地捕捉了价值。价值大致是在工件遍历其生命周期的过程中产生。
　　有了这种映射后，库存 就是指给定状态下工件的数量，而时间 则根据工件转化为给定状态所需时间的统计趋势测定。这些测量将在下面的小节中介绍。
　　要创建价值流程图来更加忠实地描述 DevOps 团队如何工作，需要一个更详细的状态模型。对于价值流程图，有两种工件状态：
流程状态：经历一次状态转换，具有多个指定资源的其中一个。
等待状态：处于积压状态，等待团队挑选并被分配一个资源，从而实现状态转换。
　　以这个 DevOps 为例。设想一个业务分析师决定是否存在新 Web 服务需求。分析师将特性提交给 IT 组织，后者为它分配一个优先级并置于积压状态并等待开发。在某些时候，开发经理将选择该项工作，这样整个软件流程就会开启。在这个例子中，这被当作完全封装的子流程。最后，开发出带有该特性的新应用程序并等待 IT 部署。现在这项工作处于 IT 积压状态。当 IT 选择了这些工作后，它会再次进入等待状态，这一次将等待来自分析团队的客户反馈。这个示例的最终状态就是该特性被交付给客户并完成评估。
　　对于一个软件应用程序的新特性，这个例子可以具备以下流程状态模型：
提交以分配优先级（等待状态）
进行考察（流程状态）
获得开发许可（等待状态）
工作（流程状态）
完成（等待状态）
部署（流程状态）
部署（等待状态）
客户评估（流程状态）
完成客户评估（最终状态）
　　在本例中，价值流程图类似于图 2 所示。
　　图 2. DevOps 的价值流程图示例
　　在这个价值流程图需要注意的地方是：
流程块与状态转换是对应的。
库存或积压表示等待状态中的工件。
团队从他们的积压工作中取出工件并推入到下一个团队的积压工作中。
推入操作可以并且经常来自于上游。例如，在部署阶段未通过测试的一个新特性将被重新推入到开发积压工作中。
　　注意，使用价值流程图并不以任何方式暗示这是一个瀑布流程。然而，您可以使用价值流程图表示不同流程之间固有的低效性。例如，在一个典型的瀑布流程中，工件将被堆叠到一组积压工作中，等待进入下面的阶段。例如，收集所有代码等待进行系统测试。价值流程用于理解工作在流程中的进行情况，不管团队使用什么流程。
　　如图 3 所示，在价值图中可以找到两种测量：
流测量：解释工件如何经过状态转换。这些测量包括端到端 (lead) 时间，流程中每个状态的时间（底部的线），以及字母 I 开头的每个状态（符号）中工件的数量。
流程状态测量：描述团队在实现状态转换过程中的效率。这些测量将检测是否因为处理能力不足或流程效率低下而引发瓶颈问题。 流程块中的黄色方框提供了有关流程低效性的测量。
　　图 3. 价值图上的测量
　　流和流程测量是一前一后使用的。流测量用于找出需要关注的流程。流程块测量则确定如何改进这些流程。例如，如果您在某个流程步骤发现了一个瓶颈，考虑是否有足够的团队处理能力。看看是否能够通过提高流程效率、实现自动化等避免不必要的浪费，从而解决这些瓶颈问题。
　　流测量
　　精益组织侧重于最小化库存，明确地管理积压工作，然后将工作量与团队处理能力进行匹配。这些做法的优点在 （Reinertsen，2012）一书中进行了介绍。这些做法已经在制造业、后台系统记录或物流系统中发展成熟。流测量提供了必要的信息来应用这些实践，从而实现精益目标。
　　有两种类型的流测量：
工作量：各个状态下的工作量趋势。这些测量揭示了流程中存在的瓶颈。
时间：工件花在各种流程状态或流程状态集合中所花时间的统计趋势。
　　工作量测量
　　工作量测量相对比较简单。它们是指在每个等待和流程状态中工作项的数量。图 4 显示了一个图形示例。
　　图 4. 给定状态下工作项数量的趋势
　　时间测量
　　时间测量更加有趣。每个工件在每个状态或若干状态集合中可能花费不同的时间。这种差异是软件固有的；不是因为缺少流程控制而导致的。在制造业中每个成品都是相同的，差异可以指示出需要进行控制的区域；软件行业的成品与制造业不同，需要预计时间和工作量差异。
　　考虑到这一点，向软件开发应用流程原理的关键因素之一就是队列中达到的成品存在持续的变化。实现状态转换所需的努力程度也存在差异。
　　由于要测量来自特定填充的工件在给定状态下所花费的时间长度，因此需要对填充时间进行统计测量。在制造业，由于成品都是类似的，所以一个标准统计项就是平均时间。团队会跟踪工作项处于积压或半成品状态下的平均时间。
　　在制造业中，工件都是一样的；因此，时间分配通常被认为接近一个差异很小的通用值。更确切地说，时间分配被建模为一个标准（也称为 Gaussian）分配，具有很小的标准偏差。在本例中，分配的平均值非常适合。在制造业工作流中，产品非常相似。然而，在创建软件时，每个应用程序都是不同的。对于软件，时间分配通常并不标准甚至是狭隘的。我们在 IBM 的研究发现软件的时间分配类似于图 5 所示。
　　图 5. 典型周期时间统计。箭头指向 T80 点。
　　尽管这种分布看似让人吃惊，但是可以合理预测接近左侧轴线的峰值。大多数工作项在一个很短的时间内解决，但是一些工作项可能长期处于某个状态。一个好的测量选择就是选择 80 个百分点：T80。也就是说，当前状态中 80% 的工件花费的时间小于或等于 T80。 其他花费比这更长的时间，因此位于分布的尾端。通过使用 T80
点，您可以测量工件花在积压或转换期间的时间趋势。
　　考虑一个更微妙的问题。因为每个成品是不同的，因此用于它们的工作时间也不相同。工作项被推入到下个团队的积压项是偶尔进行的。成品到达积压项的时间间隔也是变化的。一种比较适合的数学模型就是 Poisson Distribution。这种情形有别于制造生产线，后者在工作站之间的产品流比较稳定。对于软件而言，特定工作站的处理能力是固定的，您可以预测积压的大小来显示差异。差异通过生命周期显现并导致图 5 所示的柱状图。
　　要捕捉时间趋势的统计数据，一个不错的选择是 T80 点历史，如图 6 所示。
　　图 6. 时间趋势图
　　测量循环
　　软件开发的一个重要特性就是成品在产品流中经常向上游移动。例如，某个代码模块可能没有通过特定级别的测试，因此被推回到开发转换流程的积压工作项中。这一操作并不会影响如何测量工作量或端到端时间。端到端时间包括工件花在各个状态中的时间的总和。
　　然而，问题是如何处理各个状态的持续时间统计。您是否为工件分配了状态时间，最近一次重新进入某状态的持续时间，或它在整个生命周期内花在该状态下的总的时间？答案是都很重要：每个时间都用于不同的用途。第一个用于当前的流程调整，第二个测量返工，用于整体的流程改进。
　　流程块测量
　　精益实践人员将测量流程块之间的工作流，并且测量团队的效率和处理能力。
　　以下测量适合以工件为中心的工作：
人员可用性（AOP）：指定人员实际花在状态转换上的时间百分比。
设备可用性（AOE）：指定设备（例如服务器）用于状态转换相关处理上的时间百分比。
工作内容时间（WCT）：实际用于状态转换上的工作百分比。
非增值时间（NVA）：用于其它对成品没有推进作用的事务的工作百分比。
　　前两个测量可以看出团队在处理状态转换时的效率。后两个测量可以看出团队的处理能力。
　　信息架构和向下钻取
　　在软件和软件开发中，工件的状态通常取决于一些子工件。例如，系统架构师对业务请求进行分析后将生成一些工作计划，这些工作将分配给一个或多个团队。这些工作将进一步细化为用户案例并最终生成代码模块。代码模块被放到编译流程中以进行系统测试和发布。要确定交付的代码与最初的业务请求的匹配程度，您需要了解一些状态，子工件的状态（用户案例、代码模块和测试用例），以及它们与应用程序和发行版的集成。类似地，子工件流程中的某个瓶颈会导致交付业务请求或其中一个计划工作项时出现瓶颈。例如，交付新特性的状态取决于代码模块的状态。您可能会认为只有当所有已确定的模块已被识别并处于开发中，才能认为某个特性处于开发流程中。除非所有模块完成编码并集成到变更集合中，否则不能认为该特性已经完成。
　　出于这个原因，支持工件流测量的查询需要能够捕捉工件信息架构的链接。流程块标注包括了对父工件和子工件的引用。
　　使用测量
　　在企业中，测量得到合理使用并响应循环，引导企业朝着实现目标的方向前进。这些测量可用于支持精益计算的所有方面：
精益项目或项目监视
　　为了支持这些用途，您需要理解它们之间的微妙差异，从而了解需要对哪些内容进行测量。
　　精益转换
　　精益转换包括以渐进的方式应用一组操作实践，比如以下操作：
明确地管理队列
管理批量大小
针对需求平衡处理能力
减少非增值工作
　　要成功应用这些原则，企业文化必须发生转变。改变企业文化对于应用精益实践非常重要（）。如前所述，价值流程图及其指标是实现这种转换的常用工具。
　　测量提供了基本事实，这样所有人都可以看到改进空间，比如流程瓶颈，指出哪些时间被浪费了，以及存在过量处理能力的区域。有了这些信息后，团队可以根据这些信息采取相应的措施。事实上，使用测量可以增强团队的工作能力。
　　在本例中，您感兴趣的是企业在最近一段时间内针对一组目标转换的执行情况。实际上，问题在于 &工件 X 从状态 A 转换到状态 B 需要花多长时间&？ 阐释了这个概念。这里使用了测量获得企业的垂直视图。例如，如果有超过一个团队管理某种工件的同一状态转换，那么考虑使用综合测量，其中包括对团队积压工作和转换执行情况的测量，从而获得对企业总体情况的了解并对团队进行比较。。
　　图 7. 使用流测量实现精益应用
　　使用这类流程测量后，您可以逐步地应用精益方法，找出需求最大的位置。
　　精益监控
　　在第二个例子中，想象一下精益转换已经开始执行，并且测量框架已经就绪。由于软件固有的变化特性，需要对流程进行持续监控，从而解决瓶颈问题。通过监视流程的大小和时间统计数据，管理人员和团队可以共同做出最小的优化更改，比如切断提交，或临时变换员工角色，比如安排开发人员进行测试工作。对于这种情况，对于每个状态对儿，您需要按天查看工件的数量和存在时间，如图 8 所示。
　　图 8. 对监视使用流测量
　　另一种使用流测量的方法是理解工作的完成状态。判断项目是否完成的最佳方法是评估工件的状态。标准燃尽图非常重要；从其中可以看出哪些工件已经完成，哪些工件正在处理当中。然而，标准燃尽图缺少工件在整个生命周期内的详细状态。这些测量可用于查看哪些工件占用了最多的时间。这些报表的关键特性是能够找到在给定状态花费时间最多的工件，利用信息架构确定子工件的进度情况。
　　结束语
　　据说，要实现精益方法，则需要关注工作而不是员工。将重点放在工作上，而不是放到成品及其状态转换上，这使得您不仅能够对高度重复的、处理相同产品的流程应用精益方法，还能将这些方法应用于存在显著差异的流程。
　　增强状态转换为定义测量指标提供了基础，从而能够实现以下目标：
对精益转换进行计划并跟踪结果，满足 DevOps 目标并衡量采用 DevOps 实践的结果
监视和引导 DevOps 企业
软件工程热门文章
软件工程最新文章1179人阅读
技术管理（12）
在本文中我们将会讨论一些人们对DevOps的误解，同时会介绍一个能够带来DevOps文化转变的流程。
在一篇题为“”的博文中，Cloud Technology Partners公司的副总裁兼首席架构师Mike Kavis谈论了一些与DevOps相关的错误想法。例如，他提到一些团队是如何误用术语DevOps的：
企业正在为DevOps苦恼。他们都想得到DevOps，即使很多企业并不知道它到底是什么。在很多情况下，我会看到那些自称DevOps的基础设施团队在领导一个基层倡议。当我问他们开发团队在哪里的时候，他们通常会说“我们并没有邀请他们”，甚至更糟“我们并没有同他们交流”。
一些工程师将自己宣传为DevOps，但是他们并不是，因为根据Kavis所说“DevOps并不是一个人，一个角色或者一个头衔。即使你可以声称自己是一个DevOps工程师，但是这仅是你自己的看法，实际上你并不是。”如果DevOps不是一个角色，一个资格，一个头衔 ，那么它到底是什么呢？Kavis的定义是：
DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。
然后他详细描述说：
DevOps是软件开发生命周期（SDLC）从瀑布式到敏捷再到精益的发展。DevOps超越了敏捷，它的关注点是从SDLC中移除浪费。通常情况下，发现浪费或者瓶颈的形式包括：不一致的环境，人工的构建和部署流程，差的质量和测试实践，IT部门之间缺少沟通和理解，频繁的中断和失败的协定以及那些需要珍贵的资源、花费重要的时间和金钱才能保持系统运行的全套问题。
我看到的另一个重复模式是：一个“DevOps”团队的第一步通常是决定他们是否应该使用Chef或者Puppet（或者是Salt、Ansible等其他任何热门的东西）。他们甚至还没有定义自己打算解决的问题，即使他们手头的工具可以解决它们。这些团队通常会紧张地构建数千行脚本，但是这就产生了一个问题：“我们的职责是编写Chef脚本还是通过质量更好、更稳定的产品更快地进入市场？”。在大多数情况下，这些团队会将自己逼入绝境，大量的专有脚本实际上是增加了系统的浪费，而隐藏在DevOps运动之后的驱动力是从系统中移除浪费，这些团队并没有做到这一点。
如果说DevOps是一种打算让开发某个产品的多个团队之间能够更好的交流和协作的文化变革，那么下一个问题就是我们该如何实现DevOps，我们如何将这种文化引入到自己的公司中？
的共同创建者Damon Edwards在2013年的DevOps Days Mountain View上做了题为“”的主题演讲，他推荐通过一个三步走的过程将DevOps文化引入到某个组织中：
1.弄清楚“为什么？”
根据Edwards所说，首先非常清楚组织成员为什么会聚到一起，知道他们试图实现什么，清楚他们的目的是什么是非常重要的。为了找到这些问题的答案我们应该直接与组织中的这些人交流，询问他们为什么会出现在这里。组织的主要目标是我们实现DevOps文化的唯一原因，除此之外没有其他原因。
Edwards认为DevOps仅仅是达到目标的一种手段，但是它自己本身并没有结束：“DevOps并不是你的为什么，不是你合作伙伴的为什么，当然也不是你业务的为什么”。他甚至建议忘记DevOps团队，而是使用服务交付作为替代，因为“我们的职责是创造服务”。
2. 实现组织合作
按照Edwards介绍的过程，接下来需要做的是使整个组织合作，让所有人基于一组共享的条件和规则向一个共同的目标努力。当你能够把同一个目标指定给多个人的时候，一个组织就实现了正确的合作，他们会选择同样的方式去实现各自的目标；他们对于同一个问题有同样的答案。这可能是“组织合作的终极梦想”。
为了完成这种合作，组织内部必须要有人描绘一个DevOps愿景。这并不能通过教学过程实现，因为人们只会尝试着机械性地遵循这些步骤。我们需要的是教会大家一种思维方式。根据Edwards所说，这可以通过遵循下面的几个步骤实现：
教导基本的概念，例如“单件流、批量工作、限制在制品的数量、拉式vs推式、持续交付”以及可以使用的工具等组织将会共享的一些通用词汇的概念。让所有人目标一致，通过：
a. 价值流程图——一个精益概念，它详细描述了一个组织内部发生的信息流和制品流，引导价值创造。
b. 时间线分析——试图发现时间花费在哪里，瓶颈在哪里。
c. 浪费分析——确定一个组织所产生的各种各样的浪费以便于尽可能地消除浪费。发展度量链，它的意思是对价值交付链中的各个活动进行度量，发现各个活动相互之间的影响。针对基线识别项目/ 实验。识别哪些项目或者活动偏离了基线，并且采取纠正措施。重复第2至4步。这一步构成了持续改进流程。
为了实现这些想法，Edwards建议了一个3天的计划：
第1天—— 教导原则，提出一个方案进行研究，模式和反模式第2天——分析组织当前的状态，提供问题识别技术和改进指标第3天——讨论解决方案和工具链自动化原则，构建一个路线图
3.持续改进循环
这些循环的目的是通过制定计划、实现计划、测量输出和决定如何持续地改进流程。
在最近举行的QCon London 2014上Edwards做了题为“”的分享，其中就讲到了这些原则，稍后这个分享将会发布到InfoQ上。
查看英文原文：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1363794次
积分：15054
积分：15054
排名：第635名
原创：242篇
转载：297篇
译文：10篇
评论：297条
文章：22篇
阅读：51853
阅读：11247
文章：14篇
阅读：36023
文章：58篇
阅读：150886
(3)(5)(4)(3)(4)(7)(15)(12)(16)(17)(5)(16)(13)(7)(10)(15)(8)(12)(18)(33)(8)(10)(3)(7)(3)(4)(5)(10)(9)(17)(27)(26)(22)(7)(1)(5)(2)(1)(1)(1)(3)(2)(3)(1)(1)(5)(2)(2)(1)(2)(2)(2)(3)(3)(14)(5)(16)(9)(15)(7)(16)(8)(1)(1)(1)(1)(21)(1)(4)(1)(1)(2)(3)(2)(1)(1)(4)(3)(1)中国领先的IT技术网站
51CTO旗下网站
外媒速递：DevOps实现成功所必备的11种编程语言
DevOps需要利用各种编程语言实现软件开发与自动化部署。如果大家希望在自己的DevOps举措当中赢得成功，那么这11种语言绝对不容忽视。
作者：核子可乐译来源：| 10:10
外媒速递是核子可乐精选的近日国外媒体的精彩文章推荐，希望大家喜欢!
本期给大家推荐的是DevOps必备的11种编程语言、值得关注的安全初创企业、你的工作负载如何做好迁移到云的准备和成功规避数据库陷阱的步骤等。
一、DevOps实现成功所必备的11种编程语言
原文标题：
DevOps需要利用各种编程语言实现软件开发与自动化部署。如果大家希望在自己的DevOps举措当中赢得成功，那么以下11种语言绝对不容忽视。
1. 微软PowerShell
8. JavaScript
二、值得高度关注的几家安全初创企业
原文标题：
模拟攻击、物联网保护与异常设备重配置状况追踪，众多年轻的初创企业正在利用自己的聪明才智为安全领域带来新的突破。下面就来一同了解其中几家值得关注的后起之秀：
1. Arctic Wolf Networks
2. AttackIQ
3. Cato Networks
5. Datiphy
7. SafeBreach
9. Simility
10. Trusona
11. Upguard
12. Verodin
13. ZingBox
三、每位从业者必须了解的四项基本安全事实
原文标题：
如今的安全背景可谓纷繁复杂，即使是专业人员往往也无法将其彻底掌握。那么，作为技术从业者，我们又该如何审视相关问题?坏消息是：我们对抗的是一大群来自世界各地的犯罪分子。但好消息是：只需小部分知识的协助即可建立有效的防御体系。
1. 大多数攻击起于两大源头：未经修复的软件与受到愚弄的用户。
2. 大部分恶意软件由木马构成。
3. 大多数用户会轻松泄露登录凭证。
4. 杀毒程序仍然必不可少。
四、你的工作负载是否做好迁移到云的准备?三个问题快速揭晓答案
原文标题：
大多数应用工作负载都需要经过调整才能运行在公有云环境之下，但有些则能够直接完成迁移工作。面对这一重要的前提性问题，我们该如何做出判断?通过以下三项测试，大家将能够准确地把握当前状况，了解现有应用是否做好了前往云端的准备。
1. 数据是否从应用中解耦出来?
2. 应用是否不涉及任何陈旧安全框架?
3. 应用在设计当中是否考虑到了多平台部署需求?
五、五步走战略助你成功规避数据库陷阱
原文标题：
数据库的健康与高效运作需要适当的管理作为配合。在今天的文章中，我们将共同了解五种实现这一目标的重要途径。
1. 主动关闭并重载数据库以确保数据安全性
2. 在另一设备上测试备份与恢复能力
3. 测试灾难恢复规划
4. 检查数据库的文件规模增长情况
5. 高度重视各项性能指标
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
外电外电头条头条头条
24H热文一周话题本月最赞
讲师：4人学习过
讲师：14人学习过
讲师：8人学习过
精选博文论坛热帖下载排行
本书是在第1版的基础上全面更新、改版而成的，仍然是目前图书市场中唯一一本全面介绍硬件服务器的IT图书。本书针对近两年来所出现的新服务...
订阅51CTO邮刊