【51CTO.com原创稿件】长期以来，我们着眼于IT基础设施，硬件设备和软件应用的运维;并且一直践行着用ITIL这样的框架来优化和治理所提供的各种服务。但是随着我们的企业开始将业务向云端进行拓展、部署或是迁移，咱们许多IT运维管理人员的工作职责与内容也发生了潜移默化的变化。
无论面对的是私有云的系统、公有云的服务还是混合云的架构，我们从基础细节提升到了管理迭代的层面上。伴随着这种工作内容上的level up，爱思考的您是否考虑过一个问题：ITIL的“前半生”已为我们的企业IT服务治理带来了不少的红利，如今的云服务时代，它是和权游一样面临着“Winter is coming”呢?还是能继续“春风十里”呢?它对于企业各种云业务的管理是否还适用呢?答案这里先不给出，且让我慢慢用ITIL v3的管理概念来试着和给大家探讨一下对于企业云服务的治理吧。
大家都知道云服务吸引企业的地方在于：按需分配、快速发布、弹性伸缩、和资源池化。而我们常用的ITIL v3所涉及到的服务生命周期则包括：服务设计、服务转换、服务运营、服务改进。细心的小伙伴一定会问：那么“服务策略”呢?这个策略嘛，比较高端，讲真，我们做运维的参与的机会并不多，所以在此暂且不表。因此，我们不难发现云服务和ITIL的各自四个特点是隐约存在着一定对应关系的。
服务设计vs.按需分配
在这个层面上，我觉得和以前内部IT系统的管理流量并没有太大的不同之处，我们更应该注重从业务和产品需求出发，对于任何要迁移到云端或是新增的云业务都须做好服务编录设计、级别配比、和安全预设的工作。
1. 编录设计
首先要做好产品和服务的分类与编录。比如说，在典型的应用场景中，企业所可能采用的云服务功能领域包括：生产环境云、开发测试资源云、内训教学云、桌面云、以及运维资源云等。在每一种云服务里，我们可以根据数据和服务类型进行细化，根据各个应用和不同系统之间的数据流向，勾勒出流转的图表，清晰地定义出何种类型的数据将会在逻辑上或物理上存储在何处，它们是如何在组织/系统间进行流动，以及它们会受到何种方式的管理和保护等。当然，由于云业务突破了地域上的局限性，我们也要适当地对数据的存储和可能在迁移时所涉及到的当地相关法律及监管要求予以研究和说明。
2. 级别配比
随着企业云业务的深入，我们以往对于用户和客户的服务承诺与品质保障被逐渐地从日常工作中剥离，进而部分转移到了云服务商那里。在大多数企业的实践中，IT部门降低了以往运维工作的比重，而会花更多的时间从RTO和RPO出发，去评估包括基础网络带宽、高可用性、并发数、响应时间、存储频率和备份深度等指标。
他们通过与云服务商进行协商和约定，进而界定出那些本企业与服务商之间，以及各个服务商之间的易重叠或不清晰部分，以免出现“踢皮球”的情况。这对IT部门来说既是原有服务级别的保持与延续，又能保证合理的服务资源的分配，同时还为我们马上要提到的安全预设做好了基本准备。
3. 安全
曾经有不止一个运维部门的小伙伴向我抱怨：“一入云端深似海，从此安全是路人”。那么到底有多深呢?让我们具体从如下不同的角度来分析一下吧。
首先是在物理上，可分两部分：
- 对内，有用户桌面云和私有云的安全。此方面我们有着以往安全实践的经验，还是同样的操作，熟悉的味道，在此就不赘述了。
- 对外，则是云服务商或者是我们托管在IDC处的安全。他们大多数情况下仅提供入站防火墙功能，而没有出站控制。不过这个也比较好理解，因为具体的应用环境和服务是由咱们的团队所自行搭建的。所以我们可以添加云WAF，通过将DNS的记录进行重定向，由云WAF来过滤各种未经验证的访问流量之后，再转发给真正的云Web应用。
其次是在逻辑上，其“任督二脉”是：相对动态的数据和相对静态的应用。
(1) 在一般云业务中，数据仍旧遵循着“创建->存储->使用->共享->传送->归档->销毁”的生命周期轨迹，所以我们应当：
- 在创建与存储阶段：做好数据本身的加密。
- 在使用与共享阶段：通过部署在虚机或是hypervisor的agent对元数据(如数据属性标签)的检索来实现DLP(数据防泄漏)。
- 在传送与归档阶段：采用SSL/TLS、VPN或SSH来实现数据的屏蔽并保障完整性。
- 在销毁阶段：清理数据残留并予以脱敏或替换，以免泄露给在云空间里物理上交错的其他租户。
(2) 而对于云应用方面的安全，我们可以采取身份和访问管理(IAM)，在确保各种来自AD、LDAP或其他SaaS服务商的用户账号信息能够在内部同步的前提条件下，利用SAML、XACML或Oauth来基于角色和权限的映射矩阵，保证用户仅能看到他们有权访问的数据。
可见，对于IaaS模式的业务来说，由于从系统层面上为我们所掌控，因此完全可以利用各种工具和手段，给系统做“大保养”，来保证各类云资产和服务的安全。而SaaS则相反，由于我们能够访问和掌握的信息源数量最少，因此其安全责任主要是服务商所承担，而约束性合同则是我们的唯一抓手。
二、服务转换vs. 快速发布
云业务的弹性灵活和快速转换的特点虽然是那么的“金光闪闪的”，但是也给我们运维团队带来了配置和变更上的复杂性。以往，我们一旦在系统的初期完成了配置与部署，就能够管上一段时间。而变更更是能怼就怼回去，实在顶不住也要通过规范的流程来谨慎行事。而现在呢?由于“试错”的成本降低了，各种“花式”的变更需求已经成为了家常便饭，配套的配置信息也像松鼠屯粮一般妥妥地上涨。
1. 配置
我们在过往的廉环话里有讨论过有关配置管理方面的各种实践。这里，我们着重来聊一聊和云服务有关的配置方面的问题。对于企业内部桌面云的配套设备而言，虽然很多已经做到了OOTB(开箱即用)，但是一些例行的升级和资产的录入与统计，还是需要我们IT人员去持续跟进的。因此我们仍然有必要本着“做一看二想三”的宗旨，搭建和维护好一个配置管理数据库。该CMDB除了能够根据后期实际需求进行各种表项和字段的扩充以外，还应当使得保存在其中的各种配置基线具有可移植性，以方便根据不同的云服务应用场景进行灵活组合和快速成型。
2. 变更
- 对于有计划的服务改进所产生的主动变更，高效的云服务已经将其出错的风险、和回滚的难度都降到了最低。我们反而应当跟上或是做好诸如镜像与配置模板的修改，云存储空间池的配额和虚拟CPU/内存资源的增减，等方面的计划与记录工作。
- 而对于各种事故或故障所导致的被动变更，以往由于我们运维部门对服务和系统的责任比较明确，因此有着绝对的掌控能力。但是如今转到了云端， IT部门就需要根据既定的协议与云服务商事先明确好各自的职责，比如说：在什么情况下云服务商有权先采取必要的变更、再通知租户;什么情况下我们的自行变更需要备案、甚至要得到服务商的批准，以免伤及其他的租户。
3. 测试
- 云服务发布之前：以往，我们需要配备专门的测试部门和人员，花费时间、腾出硬件资源、并通过购买测试软件搭建测试环境。而现在我们不但可以自行快速组建开发测试的云资源，还能购置一些24×7可用性的外部云测试环境。如此一来，我们就可以将精力专注于测试流程和内容之上，对服务的响应时间、资源利用率、容错稳定性、最大承压、和在不同负载条件下的可扩展性等方面进行全面的性能测试。
- 云服务上线之后：我们可以在征得云服务商确认的情况下(因为有时候不同服务商的允许策略会有所差异)，做好各种漏洞扫描和渗透测试，以抵御来自纵向的外部威胁和横向的其他租户的攻击。
4. 发布
- 发布方式上的转变：我们在处理云服务的更新与发布时，用得最多的就是：“让一部分人先用起来”的灰度发布模式。即：在允许一部分用户继续使用1.0版本的同时，让另一部分用户充当“吃螃蟹”的小白鼠，开始使用2.0版。如果2.0运行稳定，而且其用户体验不错，则逐步扩大范围，将所有用户都迁移到过来。可见，灰度发布方式更适合于发现、调整问题，并限制其波及面，避免被用户“吊打”的情况发生。
- 发布效率上的提升：由于云业务实现了我们运维的对象从传统的以“硬件设备”为中心向着以“虚拟实例”为中心的转变，因此在发布效率上，IT人员更能够从各种资源池中迅速地虚拟化出各种应用的实例，然后根据既定的策略实现自动化的部署。显然，这种发布流程有效地减少了以往由于全靠人工处理所带来的业务延迟或中断的可能性。
三、服务运营vs. 资源池化
1. 容量/资源池
清晰的容量和性能需求对于云服务的空间与资源的预估和购买是相当重要的，同时也能够在云业务的上线之初和交付之后的一段时间内，有效地杜绝潜在的中断和性能瓶颈。当然，我们也应该与云服务商事先制定好按需订阅或扩容条款。如果购置的是IaaS的话，我们则可以在实际需求或业务模式发生变化时，及时地根据CMDB里的模板产生新出的虚拟机、动态地增配CPU和内存的数量、以及临时将某个host迁移到他处等。
2. 高可用性/连续性
凭借着虚拟化主机和网络设备的镜像和数量的优势，我们的云业务可以充分发挥其服务的自愈和扩展能力，从而实现HA、业务连续性、和灾难恢复的效率。我们平时的各种重复单调的维护工作量也能相应地大幅减少。当然，对于那些和我们的系统有关，但由云服务商所负责的部分，我们不能只是被动地接受其例行的测试成功报告，而应当主动要求，真正地参到测试环节之中。
3. 事件/故障响应
在云业务环境中，由于突破了以往的一套系统仅能提供单一服务的限制，所以造成了应用种类、数据混杂、和设备资源相互交错的状态。我们所面对的早就不再是能否扑捉截取到事件发生的问题了，而是各种被自动采集的海量事件集中性地扑面而来，所导致的筛选、分析和去除误报的局面。
具体来说，对于采用SaaS模式的企业，可能会更多地需要依赖云服务商的来采取各种的应急响应措施。而对于使用IaaS的企业，其IT部门则有能力和责任按照我们在《安全事件响应之五步进阶》里提到的“识别和分类->调查和取证->抑制、根除和恢复”的流程进行应对。我们逆推着来看：
- 抑制是关键，我们可以通过暂停被攻破的虚机镜像，隔离它与其他系统的逻辑联系，从而既不会破坏它上面的证据，又能够阻止形式的恶化。
- 我们曾经在《安全入侵应对实务—内网侦查篇》中着重讨论过“取证与调查”。现如今，我们来到了云端，其取证的环境变得高度动态且不定，这就对我们取证的各种要素，包括确定范围、收集方式、保留语义完整、和维持证据稳定等都带来了挑战。与此同时，隐私也是不可忽略的要素，同样需要服务商的合作与支持。
- 而在各种事件的识别和响应上，我们需要考虑到由于业务系统不再孤立的存在于我们可控的环境中，所导致的那些针对云服务商的攻击也可能会给咱们系统带来的“殃及池鱼”的影响。例如：针对您所在的云环境本身或是其它租户的DDOS攻击，就算并非是攻击的目标，您的业务可用性也会有所波及。因此我们同样要做好信息的收集和事件的分析等工作。
可见，我们需要建立的是一套更全面和有互动性的日常管理流程，而非针对某个产品或项目的特定应对模式。与此同时，我们可以采用当前比较流行的大数据分析的一些工具，在实现快速综合性的智能分析的前提下，获取本企业不同应用中的云业务的全网视图，综合分析各种安全状况、安全事件和安全趋势，做到防范于未然。
四、持续改进vs. 弹性伸缩
1. 持续监控
对于我们一般的企业而言，IT运维部门做好对既有云业务的监控与管理是很有必要的。监控的重点应当放在三个方面：
- 云平台对外或者对于内部员工所提供的各种应用服务的performance。
- 在服务使用的过程中所产生的流量和费用等，也就是所谓的财务监控。
- 根据预先定义的条件和阈值，实时进行数据库活动监控(DAM)、策略违规监控、和恶意使用于入侵的监控与分析。
记住：监控只是手段，不是目的。其真正目的就是要能够实时了解到使用的需求、消费状况、和安全的态势，通过对现有云服务资源的弹性调整，从而改变以往对物理资源的死板预分配和对网络带宽的滞后的模式，形成正反馈。
2. 动态调整
技术和设施都在不断迭代和进步，因此我们可能会从整体性能以及运营成本等多方面考虑是否需要对运行了一段时间的云业务进行整体或部分的迁移。迁移的前提条件是：要保证前后服务商所提供的云服务产品的互操作性和延续性。就像以往能够在不同的硬件设备环境中部署系统那样，我们要求企业云业务的各种组件也能够被来自不同服务商的环境所替换，平滑地部署应用，并能交换导出/导入，从而最终实现无缝迁移和持续运营。
有过运维经验的小伙伴应该知道，从迁移的难度上说，SaaS>PaaS>IaaS。而可能碰到的问题会包括：旧云平台所用到的API、数据格式、标准和支持文档、业务的定制部分的旧平台依赖性和新平台的不兼容性、以及业务的起/停顺序和导致的中断等问题。因此，我们运维人员需要提前理解和做好数据备份、新应用的部署、以及切换顺序和详尽的回滚方案。同时在迁移结束、配置信息调整以及测试完成之后，我们不可马上与旧的云服务平台拗断，因为很可能需要让新旧云业务并行地运行一段时间。
3. 服务商管理
前面我们屡次提到如何与云服务商进行各种协作。但是由于他们不再会来到我们的机房或办公区，我们也不大可能常去他们的云服务机房，而且其提供的云服务也不再显而易见，那么我们最终如何考量他们的服务级别的达标情况呢?我们根据实践经验发现：只能通过设定好的报告模板和内容项的格式，并审计和汇总其呈交的各类报告，来实现远程地协调与管理，从而在整体上改善和提高其服务的“信价比”。当然，我们也可以将各个服务商予以“池化”，营造良性竞争的环境，对于无法通过自身改进来提升服务种类和质量的服务商，就只能让他去领便当了。
总的说来，在您的云业务中，如果云服务商所提供的“XX即服务”占比越多，您在治理控制方面的灵活性就越弱，他们的责任就越大;相反，倘若他们的占比越少，您的管控能力则越强，相应的负责也就越大。因此，大家依据服务合同，不应该“互相伤害”而是要“愉快地玩耍”。
小结
上面和大家聊了不少ITIL在云治理中的运用和实践。可见ITIL的服务管理“套路”还是能够在企业新的云应用场景中保持老当益壮，焕发第二春的。而作为IT运维的我们，工作内容已经从原来的单纯技术，滋长成了“技术+管理+业务”。
有经验的小伙伴也许有这样的体会，根据各个企业的实际规模、需求状况，以及云业务实现程度的不同，各类IT管理与运维人员也有着细微的专注点。比如说：基础日常运维人员会更关注于IaaS，项目、部署人员则更关注于PaaS，而业务支持人员可能主要关注的是SaaS。但是，无论您在企业中是什么角色，关注哪一方面的云服务，我都希望您能够运用ITIL这把“洛阳铲”继续深耕云业务，解锁出了更多的运维和管理的新技能。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
