一名CIO需要什么样的DevOps团队？
作者：佚名
出处 : 比特网
　　IT领导者可以从大量探索DevOps的材料以及DevOps转型所需的具有挑战性的文化转变中学习。但是，你是否与DevOps团队面临的短期和长期挑战保持一致？以及真正需要的是什么？
　　在与DevOps团队成员的中，我听到的一些内容可能会让你大吃一惊。 DevOps专业人员(无论是内部团队还是外部团队)都希望将以下内容放在CIO视野的顶部。
　　1.沟通
　　首先，DevOps专业人员需要同行级的沟通。有经验的DevOps团队非常了解当前的DevOps趋势，成就和行业失败，并有兴趣分享这些。DevOps的概念很难传达，因此应该建立一种新的工作关系，在这种关系中，关于IT当前状态的定期(不要担心，而不是每周)对话，环境中的部分如何与整体IT架构。
　　相反，准备与DevOps团队分享当前的业务需求和目标。业务目标不再与IT孤立存在：它们现在已经成为推动IT技术进步的重要组成部分，而IT则决定了如何有效执行业务需求和目标。
　　专注于参与而不是领导，在决策时，你仍然是最终的仲裁者，但要明白这些决策最好是通过协作来激励和激励你的DevOps团队。
　　2.减少技术债务
　　其次，努力更好地理解技术，以及如何减少DevOps的努力。你的DevOps团队正在这方面努力工作。在这种情况下，技术债务是指人力和基础设施资源每天通过在单一的，不可持续的环境之上维护和增加新的功能而被篡改。
　　常见的CIO问题包括：
　　为什么我们需要以新的方式做事？
　　为什么我们花时间和金钱呢？
　　如果没有新的功能，只有现有的部分被打破，那么收益在哪里？
　　“如果没有坏就不解决”的思想是可以理解的。但是，如果汽车行驶的很好，而路上的每个人都加速过来，你的环境就会破裂。珍贵的资源继续被用来支撑或增加环境的乐趣。
　　孤立地解决每一个问题导致从一开始就有一个妥协的选择，随着每个连续的补丁(逐层添加到没有支持它的基础)而恶化。实际上，这种方法类似于堵塞连续失败的堤坝。你迟早会用尽手指，在压力加大的情况下，整个事情就会被压垮，淹没你的资源。
　　解决：自动化。自动化的结果是可扩展性，每个人减少维护和增长IT环境的工作量。如果增加人力是发展业务的唯一途径，那么可扩展性就是一个梦想。
　　自动化降低了你的人力需求，并提供持续IT发展所需的灵活性。很简单，对吧？是的，但是你必须为延迟满足做好准备。为了获得自动化的后端财务收益，提高生产力和效率，需要投入大量的时间和进行架构和结构的改变。作为IT领导者接受这些挑战对于您的DevOps团队成功执行至关重要。
　　3.信任
　　最后，请相信您的DevOps团队，并确保他们知道这一点。DevOps专家明白，这是一个棘手的要求，但是他们必须拥有无可争议的支持和积极参与的意愿。随着DevOps团队不断改进您的IT环境，同时适应不断变化的技术，这通常会成为你“随时学习”的体验。
　　倾听，倾听，倾听并相信他们。通过提高效率，生产力和业务响应能力，DevOps的变化非常有价值，而且值得花费时间和金钱。信任您的DevOps团队可以让他们自由地做出最有效的IT改进。
　　新的CIO底线：为了最大限度地提高DevOps团队的潜力，请离开领导层的舒适区，接受“CIOps”转型。在整个DevOps过渡期间继续与DevOps团队寻求共同点，帮助你的组织实现长期的IT成功。
[ 责任编辑：元冬 ]
比特网 14:14:58
从《中国互联网+指数报告（2018）》看数字经济
“互联网+”的这些新变化,你知道吗？
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。我眼中的Devops——倍道而进！
发表于 14:46|
作者夏梦竹
摘要：DevOps革新浪潮来袭，也正是拜代码运动、敏捷运动推进，加速了DevOps到来。DevOps的成功运用离不开企业领导的重视、工具的运用、开发/运维人员对业务流程的掌握等因素。但首要问题是，公司为DevOps做好准备了吗？
DevOps革新浪潮来袭，也正是拜代码运动、敏捷运动推进，加速了DevOps到来。DevOps其实说白了，它就是新兴的专业化运动，而这种运动提倡的是开发者和运维之间的高度协同，这个过程贯穿整个软件开发生命周期，从业务规划到创建、交付再到反馈。在很大程度上DevOps是个集合性概念，即开发（Development）和运维（Operations）两个领域的合并。早在1990年代就出现了敏捷软件开发。它更多强调的是人与人的交互优先于过程和工具、客户协作优先于合同谈判、随时应对变化优先于循规蹈矩。随着历史变迁人们越来越认识到传统意义上的开发和运维行为存在严重脱节现象，许多公司的开发部门和运维部门存在深深的矛盾，说到底这都是脱节造成的。尽管各大公司提倡敏捷开发，但事实上这一现象并未的得到很好的改善，于是乎DevOps应运而生，在笔者看来DevOps理念强调的是开发+运维之间的协作，也可以说成敏捷开发+敏捷运维。年中，CSDN曾做过一个《》，据活动报告显示：有37%的开发者听说过DevOps，并且很感兴趣，正准备使用；有60%的用户表示只知道DevOps概念，但尚未使用，能够熟练使用的用户只占到19%。另外，根据调查数据来看，实行DevOps战略的大多数企业/开发人员基本聚集在北京、上海、广州，其中尤以北京居多，以45%的优势排名第一位，由此可以看出DevOps理念的实施与软件产业发展水平息息相关。大家眼中的DevOps反对派：DevOps正在扼杀开发者！但现实生活中，针对实施DevOps的看法不一，有部分人认为DevOps的流行让越来越多的程序员身兼多职，也就是大家所说的“全栈”。而这种流行趋势正在扼杀真正的程序员。这又是为何？请允许笔者娓娓道来。我们都知道DevOps主要强调开发人员、运维人员以及QA之间的合作与沟通。因为软件会定期的更新，发布新版本，所以，以前旧的“瀑布式”的软件开发-测试-发布流程已经变的不适用。作为开发人员，除了实现功能外，还需关心负责产品的质量测试和发布环境，这也不断催生了一个新的角色出现即“全栈”工程师。在一个创业公司里，开发者随时可能扮演着QA、测试人员、部署/业务分析人员、系统管理员或数据库管理员的角色。这样做的效果就是以“技术实用”来摧毁开发者。开发者之所以从事这份工作，是因为他们享受这份工作带来的乐趣。每个组织有层次结构，人们有不同的技能水平。倘若让开发人员扮演其他角色，或者强迫这些聪明人去执行额外的任务，其实是在伤害每个与之相关的人。而这所带来的后果其实是在摧毁“开发人员”的角色！支持派：DevOps扼杀的不是开发者，而是开发生产力！如上所述，有人认为DevOps扼杀了开发者，持反对派的人则认为，DevOps并未扼杀开发者，扼杀的则是开发生产力！这是因为在贯穿整个产品开发过程中，持续交付和持续开发取代了持续集成。如此快节奏，这也意味着开发者不得不演变为“超人”，既要搞代码，又要兼顾测试；既要对内，又要对外。Devops活生生就是多、快、好、省的代名词。由此一来，开发者的代码量输出都在持续萎缩，因为他们要把时间分配到运营工作中，帮助运营团队查找和解决问题，回复客户的咨询和疑问，监控系统，帮助执行A/B测试……面对如此繁重的任务清单，开发人员输出的代码量势必会减少！那么实行DevOps有哪些好处呢？虽然DevOps不是万能的，但至少它能帮助开发或运维节省大量时间，会使两个部门更好的交互，使两者的关系得到改善，从而让很多领域从中受益。而对于企业而言，DevOps能够给企业带来诸多利益，比如“业务敏捷性”和“IT融合”。写在最后：其实，在笔者看来，DevOps能够把不同领域不同分工的人聚集在一起，而他们的目标却是一致的，那就是共同解决问题，他们的结合有利于促进开发、运维之间的沟通，产品质量将会更满足客户需求，并且会提高开发和软件交付的速度。而DevOps的成功运用离不开企业领导的重视、工具的运用、开发/运维人员对业务流程的掌握、沟通与合作等因素。但首要问题是，公司为DevOps做好准备了吗？
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章通过区块链技术来简化DevOps流程
来源：区块网
DevOps是近年来推动技术进步的动力。DevOps为我们提供了一个进入未来的通道，在那里，软件技术始终保持最新，一切都可以在眨眼之间完成加载，你再也不会遇到另一个应用程序故障。这怎么可能？密切的团队沟通、快速反馈和关键流程的自动化让DevOps团队能够不断创新，导致传统IT看起来极其笨重而繁琐。
　　DevOps是近年来推动技术进步的动力。DevOps为我们提供了一个进入未来的通道，在那里，软件技术始终保持最新，一切都可以在眨眼之间完成加载，你再也不会遇到另一个应用程序故障。这怎么可能？密切的团队沟通、快速反馈和关键流程的自动化让DevOps团队能够不断创新，导致传统IT看起来极其笨重而繁琐。今天的软件公司已经到了做出抉择的时候：“采用DevOps，或慢慢死去。”
　　在进一步讨论这个话题之前，先让我们澄清一下DevOps的概念。DevOps是一种软件交付的整体方法，它统一了软件开发（Dev）和软件运营（Ops）。它涉及软件工程各阶段的自动化和更短的开发周期。Netflix是成功应用DevOps的最著名的公司之一——它能够通过无处不在的自动化来支持公司的快速增长，包括故障自动化（一种名为“Chaos Monkey”的工具通过定期随机关闭服务器实例来测试Netflix应用程序的稳定性）。
　　话虽如此，DevOps仍然存在一些问题——主要与自动化流程、基础设施不足以及计算能力不足有关。所幸的是，在标记化的基础设施市场、自动化GRID和人工智能的帮助下，有很多项目可用于解决某些DevOps所面临的挑战。在本文中，我们将详细描述它们并将它们与非区块链解决方案进行比较。
　　DevOps与传统IT：感受差异
　　采用DevOps的好处包括：处理安全问题所花费的时间将减少50％、故障恢复速度将提高24倍、变更故障率将降低3倍。此外，当今最具适应性和发展最快的科技公司正在使用DevOps来达到接近“随需速度（speed of need）”的目标。他们可以快速获得产品反馈，并以最小的延迟满足新出现的需求。
　　DevOps究竟与用于创建大多数现有网站的传统IT模型有何不同？
　　专注的跨职能团队
　　任何一家采用DevOps的公司都由专门的跨职能团队而不是以技能为中心的孤岛（独立部门，它们之间没有进行充分的沟通）组成。在传统的IT环境中，由三四个孤岛轮流开发新功能，有时候出现返工，需要将功能回退给上一个孤岛。但DevOps团队是自给自足的，它们由专注于一个应用程序的开发人员、测试人员、运营人员和业务分析人员组成。这样一个跨职能的团队可以在不向其他人推卸责任的情况下处理新功能。在准备好进入部署阶段时，工作就算完成了，因此不会在交接上浪费时间。根据1/4-2-20法则（每四分之一的完成时间，可以让生产效率提升2倍，并减少20%的成本），周期时间每减少25％，生产力就会翻倍，并减少20%的运营费用。
　　频繁的小批量交付
　　DevOps适用于频繁的小批量交付，而不是每年进行几次大型的发布。从DevOps的角度来看，大批量风险太大、太复杂、难以协调，而小批量可以进行必要的全面测试。如果出现任何问题，可以迅速解决。除此之外，频繁发布小版本可以更好地响应客户的需求。
　　自动化
　　DevOps文化倾向于提倡自动化，因为这样可以让团队处理创造性任务而不只是常规任务。系统自动构建和测试代码，并通过管道传递给消费者（已经通过测试）。不过需要注意的是，完全自动化不是必需的。自动化水平取决于每个团队的流程和痛点，过度自动化可能导致不理想的结果。为了达到完美的平衡，每个团队应评估自己的需求，找出瓶颈，并确定优先级——遗憾的是，并不存在适合所有需求的通用方案。
　　采用DevOps将会面临的挑战
　　如果DevOps是一种可以带来竞争优势的方法，为什么不是所有人都采用它？它已经存在好几年了，首次出现在2010年，而2018年的情况如下：只有30％的软件公司宣布完全（17％）或几乎完全（13％）引入DevOps，仅22％刚刚开始向这种方法过渡。
　　当然，最关键的是整个公司的大规模心态转变——从管理层到入门级员工。这就是为什么刚开始引入DevOps会很难以及成功完成实施会更难。大多数企业的开发和运营团队都试图实现相反的目标：鼓励前者进行创新，鼓励后者保持正常运行时间和连续性。要消除二者之间的摩擦并让他们组合在一起并非易事。这就是为什么公司管理层应该通过引入面向协作的目标和促进跨职能培训来转向DevOps。它将帮助Dev和Ops超越他们通常的职责范围，并意识到他们都处在同一个团队中。
　　是什么阻止DevOps渗透到整个行业？
　　除了企业文化的转变，DevOps的采用受到了一些不可避免的功利问题的阻碍，这些问题与基础设施、同步和自动化流程有关。沙盒专家Quali进行的调查表明，阻碍引入DevOps的主要障碍是公司文化（14％）、测试自动化挑战（13％）、遗留基础设施（12％）、应用程序复杂性（11％），以及预算限额（11％）。
　　自动化挑战
　　测试自动化是DevOps的基石之一：它让持续集成成为可能，并节省了团队的时间，让他们可以专注于更具创造性的工作。测试旨在检查一段代码是否按预期工作，以及它是否满足所有的技术或业务要求。有各种各样的测试类型，这就是为什么手动测试在DevOps流程中会不可避免地成为瓶颈所在。虽然测试自动化需要额外的努力，但绝对是值得的。对于FinTech之类的解决方案或电子商务网站等应用程序来说尤其如此——即使最小的停机时间也会导致重大的利益损失。
　　自动化测试的一个常见问题是，在资源有限的本地基础设施上运行时，可能会过于耗时。有时候，你甚至可能需要在晚上进行自动化测试，以便在第二天获得结果，甚至等到周末。如此低的速度对于DevOps流程来说是不可接受的，但很少有公司能够负担得起构建强大的本地基础设施的成本。
　　基础设施挑战
　　遗留基础设施是很多公司抵制采用DevOps的另一个原因。快速开发（DevOps的特征之一）主要基于微服务架构，与传统架构完全不同。迁移到微服务将大幅增加工作量，在大多数情况下，传统的基础设施需要进行昂贵的升级。
　　另一个与基础设施有关的问题是DevOps工具与现有IT系统的集成——集成过程很少能够顺利进行，因为涉及的变化太多。例如，Dev和Ops团队通常使用不同的工具和指标，但为了实现真正的DevOps效率，他们必须进行集成和统一——他们需要组成一个跨职能团队。
　　应用程序的复杂性
　　DevOps的最佳环境是云，原因很明显：云提供了必要的规模、最佳的速度和最大的灵活性，所有这些通常都无法在有限的本地部署上实现。云环境让开发人员可以更好地控制组件并减少等待时间。除此之外，云环境让DevOps团队能够为分配基础设施创建自助服务方法——这意味着他们不需要等待分配资源。但是，向云迁移并非总是可行的：据调查，44％在内部部署环境中运行的应用程序因为太过复杂而无法迁移到云环境中。
　　基于区块链的DevOps平台
　　现在已经出现了很多数字加密项目，以满足该行业对计算资源和基础设施日益增长的需求。它们使用了不同的技术，但都有一个共同点：激励社区发展并作为使用资源奖励的代币。
　　作为最有前途的去中心化DevOps平台之一，Buddy通过提供对两个自动化网格的访问来解决基础设施问题。受信任的高可用私有自动化网格和共享自动化网格可以执行时间密集型和计算密集型自动化操作，甚至整个管道。因此，DevOps团队可以以最高的效率完成他们的工作（并且无需担心基础设施可用性问题）。最重要的是，Buddy支持复杂的企业级应用程序、多云工作流和混合环境。
　　Buddy用户可以通过受支持的自动化操作来创建管道。目前有80个操作，不过很快会出现更多的操作，这要归功于Buddy市场。这个市场是为了鼓励社区发展和支持有才华的开发者而推出的。第三方开发人员可以向Buddy的生态系统提交自己的自动化操作，可以是有偿的，也可以是免费的。
　　私有自动化网格是由Buddy实例组成的网络，为DevOps流程的自动化提供按需自动伸缩的基础设施。用户可以在他们认为合适的地方运行Buddy实例：在他们自己的物理基础设施上、私有云或IaaS服务器上。Buddy还可以使用由合作伙伴或SaaS集成（如Google Cloud、Amazon Web Services等）提供的受信任网格。根据不同的负载，Buddy会自动创建新实例，并在不再需要它们时将它们移除。
　　共享自动化GRID在不需要受信任基础设施的情况下使用。可以向具有可用资源的Buddy实例网络分配时间密集型和计算密集型的任务。运行这些实例的用户将获得每个计算单元的BUD代币。该网格不能用于核心开发，但可用于测试（由数百个Buddy实例来运行测试将花费更少的时间）或其他不需要高度信任级别的任务——例如性能监控或可用性监控。
　　DevOps工程师还可以在Buddy沙箱的帮助下消除开发瓶颈，他们可以直接在一次性运行环境中从Git仓库运行应用程序或网站。沙箱不需要任何物理服务器或虚拟机。
　　Buddy支持与以下生态系统集成：Github、Bitbucket、GitLab、Slack、DigitalOcean、Vultr、AWS、Google Cloud、Microsoft Azure等。它还有一个内置的Git，用户可以选择使用它来托管项目。
　　基于以太坊的BUD代币旨在作为去中心化经济的基础，并在Buddy生态系统中创建积极的反馈循环。如果没有代币，平台就缺乏对参与网格计算进行激励的经济因素，因为法定支付太慢而且效率太低，不足以推动社区的发展。
　　Fetch.ai
　　Fetch.ai是一个基于区块链的智能账本（Smart Ledger，下一代分布式账本技术）项目。它为数字世界提供动力，在这个世界中，自主软件代理可以通过出售数据或空闲资源来获得Fetch代币。DevOps团队显然可以从这个市场中受益：这是一种购买计算资源以进行测试、监控或执行其他DevOps时间密集型任务的便利方式。从DevOps的角度来看，它有点类似于上面提到的Buddy共享自动化网格，只是人为干预较少。
　　这项技术还可以怎么用？简而言之，就是可以在Fetch数字世界中出售数据。物联网设备可以出售对于其他代理来说有用的信息：例如，软件代理可以将车辆挡风玻璃刮水器的使用信息作为气候信息的来源。空闲计算机可以为远程客户执行测试任务或执行其他计算。除此之外，还可以将旧数据接入Fetch并使其成为可销售的资产。
　　随着时间的推移，Fetch网络可能会扩展并获得巨大的计算能力，因此代理将获得新的数据洞察力。得益于集成到Fetch系统中的机器学习技术，网络能够自己创建宝贵的知识。最终，受信任的数字代理将能够取代人类中间人，并建立全新的行业。数据和基础设施不会像现在这样依赖人类——它们将创造新市场并进行自主销售。
　　Fetch代币将用作网络中所有交易和操作的内部货币，它们还将作为某些行为的可退还押金，以确保安全以及防止不良行为。
　　Golem项目释放了闲置计算机资源的潜力，创建了另一个带有基于以太坊的代币的去中心化市场。Golem网络是一个结合了用户可用资源的全局超级计算机，DevOps团队显然可以有效地使用它来运行密集的自动化任务。然而，这些资源的可靠性和可用性存在疑点：家用计算机（即使放在一起数量很大）是否与Buddy的受信任云基础设施一样可靠？
　　Golem网络的参与者——包括人类和应用程序——可以请求或销售机器周期。那些共享资源个人电脑或大型，都可以从Golem网络代币（缩写为GNT）的请求者那里立即获得报酬。沙箱环境提供了必要的安全级别，其中计算与主机系统是完全隔离的。
　　除此之外，软件开发人员还可以使用Golem生态系统来创建、部署、发行和货币化应用程序。Golem为这些活动提供了应用程序注册表和事务框架。
　　目前，Golem仍然处于测试阶段，因为它的创建者专注于让它变得更加强大和灵活。他们还计划为开发人员和软件公司添加各种工具，让Golem成为云提供商的可行替代方案。
　　本文中提到的基于区块链的平台解决了对计算资源的迫切需求，计算资源在未来几年必然会变得更加严峻。虽然传统云提供商在提供基础设施和计算能力方面似乎非常有效，但在社区参与和独立性方面，去中心化解决方案更具前景。一旦它们获得足够的动力，就会开始以自己的方式发展和成长，吸引有才华的开发者，这些开发者将带来新的功能和可能性。人工智能、机器学习和其他尖端技术将推动它们进一步发展——有一天，我们会惊讶地发现，未来已经到来。
　　基于区块链的平台几乎允许所有人都来参与这个市场，并通过销售闲置资源来赚取代币。这意味着，如果有必要，去中心化平台有可能可以利用全世界所有的计算能力。
【免责声明】中金网发布此信息目的在于传播更多信息，与本网站立场无关。中金网不保证该信息的准确性、真实性、完整性、有效性等。相关信息并未经过本网站证实，不构成任何投资建议，据此操作，风险自担。
分享给朋友吧Linux系统技术交流QQ群（915246）验证问题答案：刘遄
团队需要 IT 领导者关注三件事：沟通、技术债务和信任。
IT 领导者可以从大量的 DevOps 材料和 向 DevOps 转变 所要求的文化挑战中学习。但是，你在一个 DevOps 团队面对长期或短期的团结挑战的调整中 —— 一个 CIO 真正需要他们做的是什么呢？
在我与 DevOps 团队成员的谈话中，我听到的其中一些内容让你感到非常的意外。DevOps 专家（无论是内部团队的还是外部团队的）都希望将下列的事情放在你的 CIO 优先关注的级别。
第一个也是最重要的一个，DevOps 专家需要面对面的沟通。一个经验丰富的 DevOps 团队是非常了解当前 DevOps 的趋势，以及成功和失败的经验，并且他们非常乐意去分享这些信息。表达 DevOps 的概念是很困难的，因此，要在这种新的工作关系中保持开放，定期（不用担心，不用每周）讨论有关你的 IT 的当前状态，如何评价你的沟通环境，以及你的整体的 IT 产业。
相反，你应该准备好与 DevOps 团队去共享当前的业务需求和目标。业务不再是独立于 IT 的东西：它们现在是驱动 IT 发展的重要因素，并且 IT 决定了你的业务需求和目标运行的效果如何。
注重参与而不是领导。在需要做决策的时候，你仍然是最终的决策者，但是，理解这些决策的最好方式是协作，这样，你的 DevOps 团队将有更多的自主权，并因此受到更多激励。
2. 降低技术债务
第二，力争更好地理解技术债务，并在 DevOps 中努力降低它。你的 DevOps 团队都工作于一线。这里，“技术债务”是指在一个庞大的、不可持续发展的环境之中，通过维护和增加新功能而占用的人力资源和基础设备资源（查看 Rube Goldberg）。
CIO 常见的问题包括：
为什么我们要用一种新方法去做这件事情？
为什么我们要在它上面花费时间和金钱？
如果这里没有新功能，只是现有组件实现了自动化，那么我们的收益是什么？
“如果没有坏，就不要去修理它”，这样的事情是可以理解的。但是，如果你正在路上好好的开车，而每个人都加速超过你，这时候，你的环境就被破坏了。持续投入宝贵的资源去支撑或扩张拼凑起来的环境。
选择妥协，并且一个接一个的打补丁，以这种方式去处理每个独立的问题，结果将从一开始就变得很糟糕 —— 在一个不能支撑建筑物的地基上，一层摞一层地往上堆。事实上，这种方法就像不断地在电脑中插入坏磁盘一样。迟早有一天，面对出现的问题你将会毫无办法。在外面持续增加的压力下，整个事情将变得一团糟，完全吞噬掉你的资源。
这种情况下，解决方案就是：自动化。使用自动化的结果是良好的可伸缩性 —— 每个维护人员在 IT 环境的维护和增长方面花费更少的努力。如果增加人力资源是实现业务增长的唯一办法，那么，可伸缩性就是白日做梦。
自动化降低了你的人力资源需求，并且对持续进行的 IT 提供了更灵活的需求。很简单，对吗？是的，但是你必须为迟到的满意做好心理准备。为了在提高生产力和效率的基础上获得后端经济效益，需要预先投入时间和精力对架构和结构进行变更。为了你的 DevOps 团队能够成功，接受这些挑战，对 IT 领导者来说是非常重要的。
最后，相信你的 DevOps 团队并且一定要理解他们。DevOps 专家也知道这个要求很难，但是他们必须得到你的强大支持和你积极参与的意愿。因为 DevOps 团队持续改进你的 IT 环境，他们自身也在不断地适应这些变化的技术，而这些变化通常正是 “你要去学习的经验”。
倾听，倾听，倾听他们，并且相信他们。DevOps 的改变是非常有价值的，而且也是值的去投入时间和金钱的。它可以提高效率、生产力、和业务响应能力。信任你的 DevOps 团队，并且给予他们更多的自由，实现更高效率的 IT 改进。
新 CIO 的底线是：将你的 DevOps 团队的潜力最大化，离开你的领导 “舒适区”，拥抱一个 “CIOps" 的转变。通过 DevOps 转变，持续地与你的 DevOps 团队共同成长，以帮助你的组织获得长期的 IT 成功。
作者： 译者： 校对：
原创编译， 荣誉推出
原文来自：
本文地址：编辑：李帅，审核员：逄增宝
为您推荐一些与本文相关的文章：
Linux系统镜像及所需软件工具包下载地址：
进阶课程目录
第24章 使用Xen与Kvm部署虚拟化服务环境。（即将公布）
Linux技术交流QQ群
向每个正在奋斗的Linuxer致敬.
Linux技术交流群A:560843
Linux技术交流群B:340829
Linux技术交流群C:463590
Linux技术交流群D:915246
Linux技术交流群E:1663106
Linux技术交流群F:1653851
Linux技术交流群G:2632018
Linux技术交流群H:2636170
Linux技术交流群I:2650582
Linux技术交流群J:3026356
Linux技术交流群K:2659793
Linux技术交流群L:2659106
全国Linux技术交流群(总)：
9月0 篇文章10月0 篇文章11月0 篇文章12月0 篇文章
1月0 篇文章12月0 篇文章}