“敏”中求胜，“互联网+”时代下的敏捷运维，联想 IT管理研究白皮书第三部分
“互联网 +”业务特征催生了敏捷运维的发展。一方面面对不确定性业务需要快速试错，另一方面以用 户为中心的体验需要业务持续改进；部署速度、集成频率都已大大突破传统运维的能力。传统企业级 用户迫切需要有一种新的类互联网公司的运维模式去应对。针对市场需求，IDC 提出敏捷运维理念。
敏捷运维理念
相对于传统运维，敏捷运维是技术导向而非流程导向、强调对外价值输出而非强调对内服务输出、强调敏捷而非强调规范。
传统运维与敏捷运维对比图
敏捷运维的兴起和发展，和当前的“互联网+” 业务的以用户为中心特征紧密相关。互联网公司普遍认可以用户为中心的业务价值观、小而 专注的独立产品团队和成员责任感文化，这些 是与以往企业经营的最大不同和颠覆；以数字 化形态的产品和服务通过试错创新和持续迭代形成业务价值和竞争力。在这背后的 IT 已经不 再是业务的支撑，其本身就是生产力。“互联 网 +”IT 环境下，开发与运维紧密结合，运维 更是迎来了所谓“最好的时代”，这使得其价 值得以凸显；因此配套的工具、技能和沟通都 有了大幅度的创新和发展。
敏捷 IT 架构支撑敏捷业务，敏捷运维支撑敏捷 IT 架构，构建敏捷运维能力是打造业务创新的基石。
敏捷运维的实质是依托软件定义基础架构，通过使用自动化部署和发布工具，紧密与迭代开发相配合，为创新试错和高频迭代的业务提供匹配的 IT 运维能力。
敏捷运维框架
一方面为帮助企业更好地认识和理解敏捷运维，另一方面为“互联网+” 业务转型提供配套运维转型的指南， IDC 提出敏捷运维框架模型。
敏捷运维框架包括：目标、要素、方法、内容和对象。
敏捷运维框架解读
目标：以用户为中心的业务创新
今天企业级用户对于业务创新的需求强烈。新型业务转型关注的是对外价值输出而不是对内服务支持。
在“互联网+”时代，运维需求发生了翻天覆地的变化。过去运维目标只针对服务等级协议（SLA），而现 在我们发现四个关键词：产品、获取、体验和成本。 产品的功能，尤其是在充斥着大量移动互联 APP 的 时代，获取的方便性、可用性、移动性和一致性。
客户对于产品体验如何、访问应用的速度如何、服 务成本的高低等都决定了未来的用户粘性。可以看 出，敏捷运维的目标就是以用户为中心的业务创新。
要素：价值观、文化和组织的变革
价值观的转变
业务的创新，导致运维的关注范围和价值输出前移。
运维现在更需要关注用户体验、快速部署和持续交付。 需要从应用出发，从用户需求出发整体考虑，而不能仅局限于关注设备和资源，这颠覆了旧有的运维价值观。
组织和文化的改变和保障
相比于传统运维，敏捷运维关注的工作范围已经延伸到开发阶段，相应的需要把研发的能力延伸到运维，确保高质量、持续、快速地向用户交付价值。
系统的弹性源于组织与人的弹性，敏捷运维改变了 开发和运维之间传统的工作流程和衡量标准，因此 敏捷运维需要组织和文化上的变革来保障。
组织上的配合
首先，传统上开发团队和运维团队处于公司组织架 构的不同部门，通常具有不同管理者之间的竞争关 系，而且通常工作在不同的地点，之间相互冲突的动机、流程和工具导致了低效，存在一面看不见的“混 乱之墙”。
其次，开发人员和运维人员认识世界的方法，以及 各自所处的角色，存在根本性的差别。开发人员通 常认为变化会带来回报，企业依靠他们来应对不断变化的需求。因此他们被鼓励尽可能进行变革。而 运维人员则往往视变化为敌人，企业依靠他们维持正常业务运转和实施让企业来盈利的服务。由于变 化会影响稳定性和可靠性，运维人员有理由对它说不。我们已经多次听到过如下统计数字：在所有宕 机事件中有 80% 情况是源于自杀式的改变，很多时 候，仅仅是安装系统应用补丁就会造成生产服务器无法正常重启。
IDC 认为，敏捷运维需要开发和运维人员是一个统 一业务流程中的一部分。这就要改变之前的组织模 式，通过从企业业绩角度出发来校准开发和运维的职责和流程，确保个体决策和行为遵循这个统一的 业务流程。在敏捷运维中开发人员和运维人员被集 成到一个团体中，共享同一目标、共享质量责任、 共享面向客户的价值。
从组织架构层面看，为了应对新业务的拓展，成立新业务拓展一体化组织是个可行的办法。
文化的改变
在敏捷运维模式下，管理人员需要打造一种文化用 来促进探索精神和勇担风险的精神，这种精神可以 迫使运维人员去掌握并融会贯通新的技能，确保持续改进。因此敏捷运维组织中必须崇尚和鼓励：
• 持续不断的探索精神
• 敢于冒险和勇担风险的精神
• 倡导从成功和失败中学习
• 鼓励主动分配时间实践自动化、系统化、工具化的方式去消除琐事的存在同时也得谨记：重复和实践是融会贯通的前提。
方法：开发和运维一体化
敏捷运维承袭于敏捷开发。敏捷开发方法旨在保持 软件开发工作同步客户不断变化的需求。但是，当 从企业角度回顾一下整个开发- 运维周期，开发与 运维之间的“混乱之墙”导致了应用程序生命周期 的分裂。开发和运维分别按照不同的节奏进行，实 际上无论开发团体有多么敏捷，改变企业缓慢和迟 钝的特点是极其困难的。
“软件系统的生命周期，更多的是在使用期，而非 设计和实现阶段。那么，为什么传统思维却坚持软 件工程师主要关注在超大规模计算系统的设计和开发阶段呢？这一点值得考虑。” – 引自《Site ReliabilityEngineering: How Google Runs Production Systems》
敏捷运维可以使得敏捷开发的优势最终体现在应用 程序的部署上线期和使用期。通过考虑到快速、反 应灵敏且稳定的业务运维，使其能够与开发过程的创新保持同步，确保高质量、持续、快速地向用户 交付价值，最终将敏捷的价值输出到客户端。
• 从开发到运维的延伸，讲的是持续集成和交付、 自动化部署。比如开发人员负责产品上线与发布。
• 从运维到开发的延伸，讲的是通过持续业务运维， 将从生产监控中得到的运维数据不断分析挖掘后 反馈到开发端以支撑产品改进，运维也可通过推演系统的运行过程以提前避免可能发生的问题， 为系统架构的改进提供意见。
• 同时也要尽量统一开发与运维之间的流程和工具。
敏捷运维的实现方法最终在于开发和运维的融合和一体化。
内容：技能、工具和沟通
持续提升敏捷运维能力需不断打造三方面内容：技 能、工具和沟通。
掌握新技能以提高技术能力
-运维开发能力
海量用户和业务数据必然导致应用系统和IT 架构的定制化需求日益增加，这需要运维工程师具备一定 的开发能力和系统配置调整能力，并且能够和研发 一起快速上线新系统和新应用。开发能力已经成为 运维工程师的必备技能。
其次，为了提高自动化运维水平，运维工作中应该摒弃重复性劳动，通过编程来实现运维自动化将是 未来的趋势。同时编程也可以把一些最佳实践、方式、流程、方法都固化成代码，用这种方式去应对规模 性的扩张，应对复杂度的上升。
再者，敏捷IT架构中会引入大量开源软件的产品和技术，运维人员若有意恰当并合理地使用这些新技 术新工具并能解决使用中遇到的各种各样的问题，后期还能根据需求做定制化修改，因此对于源码的研究是不可避免的。
-运维架构能力
首先，在日常工作中，需要运维工程师从系统架构 角度主动推演系统可能的各种故障，提前找到应 对之策。
其次，之前一些厂商的主流解决方案对于运维来说 是一个黑盒子，无法自主掌握。一切的开发、运维 均需要厂商的支持与协助。但新一代开放性的技术平台和基于开源架构产品的引入、大数据的挖掘及 分析、基于安全和自主可控的需求等都需要与底层 IT 架构有很好的结合。需要运维人员对现有系统的架构有深入了解。
再者，随着容器技术、存储虚拟化和分布式存储技术、云平台和云管平台、微服务架构等新架构和技术不断衍生，要求运维工程师可以从系统架构和应用场景角度帮助企业选择适用于自己企业的新技术新产品。
总之，敏捷运维对运维人员的技能要求需要在兼顾 横向专业领域，如web 层、中间件层、数据库层等 的同时，打破技术个性的壁垒，提升整体业务运营 能力，向开发和运维全堆栈方向发展。
善用工具以提高自动化运维水平
敏捷的业务和灵活的IT 架构，使得运维不能再局限于以前的“例行公事”工作，传统的手工方式效率 低下，出错风险高，自动化手段和工具必不可少。虽然运维工作仍要确保在可控、可跟踪、可审计、 可回退的前提下进行，避免单个错误的扩大化等风 险，但自动化趋势已经不可逆转。
敏捷运维中用到的工具要远多于传统运维。除了传 统运维中要用到脚本语言、配置管理工具和系统监 控工具，敏捷运维中还要用到日志分析工具（ELK）、 版本控制与代码管理工具（github、SVN）、持续 集成工具（Jenkins）、编排工具（Kubernetes）、 持续部署工具（CodeDeploy）、开源监控工具（Sensu）、应用程序监控工具（New relic）等等。
重沟通协调轻流程
敏捷运维应对的是敏捷业务，对业务的响应要快， 这就要求在运维过程中对问题的处理不能再像传统 运维那样重流程，而应该尽可能通过企业内社交平台快速响应、快速沟通、快速处理、快速反馈。
开发和运维一体化进程中，运维和开发之间的协同 越来越紧密，协同效率的提升就在于沟通，沟通和 协调的重要性凸显出来。
对象：分布式和开放的 IT 架构
“互联网 +”新型业务的特点是面向海量用户，市场多变，个性化需求强烈。因此通常引入“分布式+ 开放”的系统架构，其特点是横向扩展和分布式部署， 常通过向集群中增加单机系统资源解决空间、性能 以及稳定性问题，其集群规模可以小到两三台x86 服务器，也可以大到上万台。数据海量但关联性较少， 使用者之间很少存在复杂的组织架构，没有上下级 关系。敏捷运维就是为了驾驭此种IT 架构对象应运 而生的。
敏捷运维成功标志
界定敏捷运维成功与否，可以尝试从以下几个方面 判断：
• 系统规模增加未导致运维工作量成比例增长 互联网类业务是爆发式增长的，如果不依赖于自动化、 系统化、工具化的不断完善和提升是无法把运维事务压下来的。通常可以以人均运维的系统量作为指标来衡量。
• 新业务上线成功率高即使在部署与发布效率大幅 提升的情况下在发布频率显著提高的基础上，依然能保证业务上线的高成功率也是成功转型敏捷运维的关键判断依据。部署 失败停机率指标保证为 0.05% 以下才是持续部署应达到 的一种高度。
• 资源快速灵活调度可满足动态匹配业务需求 面对海量的用户必然导致业务需求的多变，底层基础架构中可分配资源的灵活匹配度要高。体现了运维对架构 的熟悉程度和对资源的掌控程度。
敏捷运维发展阶段
IDC 认为，企业级用户应用敏捷运维会经过如下三个阶段：
• 互存 初期阶段，敏捷运维部门和传统运维部门是互相独立存 在的。大多企业级客户都会成立单独的部门去尝试“互 联网+”业务。新部门是一个集成团队，内部人员都是 融合性人才，其目标、价值观、团队文化和工作方法都和以前有很大不同。
• 互学 互相借鉴各自的工具和方法。传统运维部门可以尝试引 入在敏捷运维部门验证过的新工具和方法，敏捷运维部门也会从传统部门借鉴好的经验、方法和流程。
• 互融 敏捷业务最终会沉淀为核心业务，传统核心业务也落地 了很多敏捷工具和方法。随着业务和架构的互相借鉴和融合，运维模式也变为稳敏相融。
持经达变，无论敏捷运维还是传统运维对自动化、系统化、工具化的持续学习和实践是不变的。
“敏”中求胜，“互联网+”时代下的敏捷运维，联想 IT管理研究白皮书分为四部分，精彩继续，请随时关注。
网友评论