酒店行业需求分散、供应复杂，数字化底层逻辑该如何支持？

*本文系环球旅讯读者投稿，作者系鹿马智能科技CTO徐元区、首席架构师何子杰。

2020年新冠疫情的突然暴发，让酒店行业深刻体会到数字化运营理念与技术对精准防疫、恢复生产的重要意义。各地防疫隔离政策的提前获知、住客历史行程的登记与追踪、非接触式服务的提供、酒店消杀工作的管控与记录，都显著影响着酒店客户的选择与体验。从2020下半年国内酒店市场回暖的统计情况可以看出，很多城市的品牌酒店出租率已经同比恢复，RevPAR同比略有下降，在总体客源下降的情况下，多数顾客优先选择了运营规范、技术先进、安全有保障的连锁品牌酒店。 

随着科技的发展，未来的一切都将走向数字化，无论是供给侧还是需求侧。Z世代生来就习惯于使用智能手机等智能设备，他们习惯于使用各种数字化工具来解决衣食住行等问题。在这样一个时代，所有的企业都将是数字化企业，所谓数字化企业不止是采用一个新的技术平台和产品，更是企业组织本身就要转型为一种更加敏捷和鼓励创新的新形态。数字化转型并不是单一的技术改革，而是一种企业文化的变革。

引用ThoughtWorks在《数字化转型改变了什么》一文中的论述：数字化企业是以客户中心为基础，以科技为引领，在统一愿景下建立了实时战略机制和敏捷生态的生机型组织。根据这个论述，数字化酒店企业在坚持以用户为中心的同时，需要以越来越短的周期来响应外部变化，例如：

• 2020年疫情大背景下，要求酒店快速拿出无接触服务方案；
• 在walk-in散客越来越少、OTA流量越来越贵的情况下，酒店需要敏锐地捕捉诸如自媒体、直播等新流量风口，打造自己的直销渠道；
• 5G、物联网、人工智能以及边缘计算的成熟应用；
• 新时代的用户更加习惯于通过移动互联网来查询信息以及进行交易，各种新营销渠道和模式层出不穷。

而传统酒店企业的IT架构是基于封闭的PMS系统而构建，与产业没有连接，与客户没有互动，与IoT没有集成，已经越来越不适应数字化时代的酒店运营需求，严重制约了酒店新服务与新产品的创造与推广。业内不少CIO与IT专业工程师也想努力寻求突破，但由于酒店行业的特殊性——需求分散、供应繁杂、IT基础薄弱，如果不彻底从理念与技术上拥抱数字化，小修小补很难打开局面。

鹿马智能科技结合最新的云计算、人工智能、IoT技术，重新梳理了业务定义、SOP流程、软件架构，建设了数字化时代的酒店运营系统HIOS（Hospitality Industry OS）平台，从业务与技术两个方面为行业探索出一条全新的数字化变革路径。在这里分享一些实践经验与行业共同讨论、交流。

【HIOS的数字化业务理念】

在介绍HIOS的数字化业务理念之前，要先介绍一下Cynefin框架：

Cynefin框架
源：MBA智库百科

Cynefin框架最早是由威尔士学者Dave Snowden在IBM创建，该框架用于描述问题、环境与系统，根据因果关系的复杂程度，提供了以下五种场景：

1. 简单（Simple）

简单（Simple）场景有稳定的因果关系，在简单场景下可以采用的策略是：感知（Sense） -> 分类（Categorize） -> 响应（Respond），根据了解到的事实（感知），对问题进行分类，然后对应到现有规则或是最佳实践进行处理（响应）。例如，一般企业的电话客服就是一个典型的场景，可以预先制定工作流和相应话术来构建最佳实践。

2. 繁杂（Complicated）

繁杂（Complicated）场景是由已知的未知所组成的，它的因果关系更为复杂，需要专业知识和技能才能进行分析。在繁杂场景下可以采用的策略是感知（Sense）-> 分析（Analyze） -> 响应（Respond）。繁杂场景的一个例子是汽车发生某种故障进行检修。虽然汽车的任何故障都可以通过因果关系的分析来确认原因，但这种分析需要有经验的技术工程师配合专业的工具进行复杂分析才能得出结论，制定响应计划。

3. 复杂（Complex）

复杂（Complex）场景代表了未知的未知，这种因果关系无法事先预测到，而只能通过事后回顾才能推断出来。复杂场景下可以采用的策略是探索（Probe） -> 感知（Sense）-> 响应（Respond）。一个典型的复杂场景是请网红主播直播带货，无论主播人气有多高，或是产品质量有多好，一场直播带货的最终效果很难在事前进行精准预测，而只能是通过不断尝试和事后总结，才能逐渐了解到它的规律。

4. 混沌（Chaotic）

混沌（Chaotic）场景代表因果关系完全不可知，问题的原因完全不可理解，在此场景下追寻问题答案已经没有意义，可以采用的策略是行动（Act） -> 感知（Sense） -> 响应（Respond）。混沌场景下可以采用任意行动，唯一错误的行动就是原地不动。采取行动的目的是快速止损，设法将场景转为其他领域。一个典型的例子就是今年的疫情，果断行动胜过原地不动，正确应对的话，混沌场景下往往能迸发出惊人的创新。

5. 失序（Disorder）

失序（Disorder）代表不清楚应该属于哪个场景，人们意见冲突，观点杂乱无章，这时的策略是将问题分解后归属到不同的场景下进行相应的处置。

传统酒店数字化转型遇到的挑战在于，它的传统组织结构是为了处理简单（Simple）与繁杂（Complicated）问题而设计的，但数字化时代出现了越来越多的复杂（Complex）甚至混沌（Chaotic）的问题，这就使得传统酒店非常不适应。

传统企业一般采用树形科层制管理模式进行管理：

传统科层制

科层制的优点在于专业化，把问题域限制在一个较小的规模，使得新加入的员工可以很快地理解自己工作的上下文环境。但是这种科层制架构也同时形成了一个个的筒仓：

企业筒仓

如果把企业看作是向客户交付价值的交付流水线的话，我们会清楚地看到价值在构成企业的各个筒仓之间流动，最后交付到客户手中。例如，一个新的营销渠道可能是由市场部门产生了构想，由运营部门完善了规则，交由IT部门加以开发实现，同时还会需要后勤、采购部门配合，最后交付到客户手中。这就需要越来越多的跨筒仓协作进行各种探索（Probe）甚至是即兴行动（Act）。筒仓间的协同成本高于筒仓内的协同成本，这时一般会有两种方式：

• 部门间设置专职对口人进行对接，并制定相应的协同流程。这种方式的缺点在于：信息在筒仓间的传递经过了对口人的传递，存在信息失真。
• 不同筒仓的员工临时建立起协作群。这种方式更加常见，在许多企业中表现为通过企业内部聊天工具问了一圈人之后，拉起一个多部门多人的临时聊天群。这种方式的缺点是会产生大量的临时小群，使得员工被迫进行大量的上下文切换，每当新拉一人入群，都要重新介绍一遍当前上下文。另外在协同结束后(可能成功，也可能失败)，这些临时小群就地解散，无法将好不容易建立起来的协同机制沉淀下来复用。

筒仓结构导致试错成本很高，而数字化转型要求我们不但要有一个敏捷和快速响应的IT系统，更重要的是建立起一种全新的数字化运营的文化。降低探索成本、提升试错效率需要两个前提：

• 鼓励自治的文化；
• 支持自助式服务的弹性数字化平台。

这种数字化运营平台具备5大要素特征：

• 可以快速交付的基础设施；
•  基于API和架构治理所构建的生态系统；
• 通过数据自服务获取商业洞见；
• 打造创新实验基础设施和监控体系以鼓励有序地创新；
• 管理客户触点打造一致的体验。

HIOS的数字化业务涉及传统的PMS、CRM，同时也包含了直销渠道、收益管理、供应链管理、智慧设施等，有四个核心理念：

• 首先是增加了PMS系统的可编程能力；
• 其次是加强与顾客的连接和互动；
• 再次是简化业务流程和交互；
• 最后是赋能酒店IT基础构造的开放能力；

可以猜想，未来的酒店集团中央会形成一个大的技术平台，负责技术研发；而这个中央技术平台的产出，会被用来赋能旗下的各类品牌、门店、从业人员，将他们的潜能激发出来。IT数字化平台将不再是酒店企业的成本中心，而是各酒店集团强大的创新驱动引擎。酒店管理集团将会转型为数字化企业、科技企业，它的产出将是标准以及配套的科技工具链。

要实现HIOS的数字化业务平台，离不开云原生的理念与技术，使得酒店企业的文化转型、管理转型、组织转型同业务转型、技术转型相得益彰。

【HIOS的云原生技术实践】

云原生一词近来很热，但什么是云原生呢？国内技术界众说纷纭，有些概念似是而非。

首先我们看什么不是云原生？云原生并不是指软件运行在公有云上或私有云上，仅仅是租用云服务器或是使用公有云平台并不能使得基础设施云原生化。近些年业界流行的"Lift & Shift"的模式，也就是不对传统应用架构进行大的改造，直接迁移到IaaS公有云或私有云上。这种上云方式的优点是成本低廉、耗时短、可控性高，但缺点是即使运行在公有云或私有云上，仍然无法享受到云计算所提供的高度弹性伸缩等优点，并且由于这种模式并没有改变研发模式以及编排、管理基础设施的方式，所以并不能提升研发效率。

一个例子，即使某企业已经开始使用公有云，但团队想要发起一个新的实验性质项目时仍然要走冗长的流程申请预算，那么公有云的快速弹性伸缩的特性就完全无用。

恰恰与字面相反，云原生并不意味着必须使用公有云，甚至你可以使用一组树莓派微型电脑组建一个微型Kubernetes集群并部署一组云原生应用。云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统实施频繁和可预测的重大变更。

云原生计算基金会（CNCF）给出的云原生应用定义是：

• 基于容器、服务网格、微服务、不可变基础设施和声明式API构建的可弹性扩展的应用；
• 基于自动化技术构建具备高容错性、易管理和便于观察的松耦合系统；
• 构建一个统一的开源云技术生态，能和云厂商提供的服务解耦；
• 云原生基础设施与传统基础设施相比，更加聚焦于应用的交付，或者说，聚焦于借由服务的交付而实现的价值的交付。

为什么说云原生对于产业数字化变革非常重要？

价值一：能够实现DevOps和持续交付

传统的IT架构和开发模式当中，往往将开发、测试、运维等分成独立团队，各自工作，这就导致团队之间存在“部门墙”，交付物在团队之间流动的过程中，信息会有噪音干扰，价值会有损耗，并且团队间的目标可能是矛盾的(开发希望一次发布包含尽可能多的特性，而测试因为要对质量负责所以希望一次发布包含尽可能少的特性)，解决之道就是引入DevOps。

DevOps是将开发、测试、运维等价值交付流水线上的一系列的人和技术按照交付流水线组成一个个团队，团队内部成员目标一致，高度协同，并且采用高频率、小批次的交付周期，将价值交付的周期从年、月降低到周、日，甚至可以实现持续交付(即代码提交后一旦通过交付流水线的自动化验证，即可自动发布到生产环境中)，这使得团队可以在频繁交付价值的同时，快速响应来自客户和外部的变化。

DevOps循环

云原生技术降低了实践DevOps的成本，使基础设施变成一种高度标准化的，可以用代码自助式获取、管理并销毁的资源，从而使得DevOps团队获得极大的自治性。能够实现DevOps和持续交付，已经成为云原生技术价值不可分割的内涵部分。

价值二：一致的环境

阻碍频繁交付的另一个问题是环境的一致性问题。一般来说，一个产品团队会保持几个独立的环境，例如开发环境、测试环境、预发布环境、生产环境。在传统IT开发模式中，由于基础设施昂贵、持久且不易获得，所以团队会倾向于持有非常有限个环境，例如整个团队共享一套测试环境，另外维持一个生产环境；由于成本方面的考虑，测试环境的各种配置会低于生产环境；测试环境和生产环境都会是长久运行的，而对测试环境的维护不可能像对生产环境的维护那样全面。

久而久之，在测试和生产环境之间会产生越来越多的不一致，我们称之为配置漂移。随着配置漂移的增加，会出现越来越多的由于环境不一致引发的错误和问题，导致即使测试环境测试通过，发布到生产环境依然会是一项危险的冒险。

云原生技术采用了基于声明式代码的基础设施编排，以及类似Kubernetes这样抽象的编排系统，使得云原生应用可以被平滑地在不同公有云、私有云甚至是开发者的笔记本之间进行迁移；选择在私有云部署生产环境的团队，也可以同时在公有云上维护多套短生命周期的测试环境而无需争夺同一套共享测试环境，其配置可以靠近生产环境，在测试完成后销毁相应的测试环境，充分发挥公有云弹性伸缩的特性。

价值三：避免供应商锁定

供应商锁定通常被定义为“专利锁定或客户锁定，这使得客户依赖于供应商的产品和服务，无法在不产生大量切换成本的情况下使用其他供应商。简而言之，如果绑定到单一供应商（包括云供应商），一旦想要切换服务提供商，这将消耗时间和金钱。一般，云厂商倾向于加强供应商锁定，增加云平台粘性，使得用户无法迁移到其他平台。

由于云原生操作系统在底层云平台之上提供了一层抽象层，再借助于类似Helm等云原生应用交付工具，可以很大程度上避免依赖于某供应商独有的技术和产品，从而避免供应商锁定问题。

价值四：提升基础设施代码复用性

由于云原生系统使用的容器采用了分层存储的镜像格式设计，所以可以按层构建高质量的基础容器镜像，使得某些能力的复用变得更简单。例如，集团可以针对特定Linux发行版定制安全加固版本以及统一监控探针的安装，并且通过相关云原生工具强制后续部署的应用所使用的镜像必须基于这些安全镜像来构建，这样就可以最大程度地确保安全性和可维护性，提升代码的复用性。

我们可以像拼装乐高积木一样使用成熟的基础设施代码模块来拼装基础设施，同样的，借助于基础设施即代码工具，我们可以编写或者使用高质量的基础设施模块代码，确保应用所使用的各种基础服务都是安全、健壮、稳定的可信应用。

价值五：更高的部署密度

单台服务器可以部署更多的应用。云原生主流使用容器技术，容器相当于进程，所以相较于虚拟机或者裸金属机，容器技术可以实现更高的应用部署密度，配合云原生调度系统，可以充分利用已有的计算资源，节约硬件开销。

价值六：为产业吸引人才，提升技术人员的满意度

技术人员非常喜欢追逐潮流，为了自己的职业生涯考虑，优秀的技术人员总是愿意在日常工作中使用一些最新最流行的技术。云原生是目前最火热的互联网后端技术，采用云原生技术可以吸引对云原生感兴趣的优秀人才加入到酒店行业，也可以提升已有技术人员的满意度，使得他们更愿意在当前环境下工作。

HIOS业务平台的研发与迭代运营完全吸收了云原生的理念与技术框架，保障了与KA客户展开深度合作的可能性。在混合云的灵活部署、PMS的能力扩展、灵活的定价策略、IoT设施的集成控制等方面发挥了前所未有的作用。并且在实践中秉持了“康威定律”——设计系统的组织，其产生的设计和架构等价于组织间的沟通结构，优化了研发团队的结构与协作模式，提升了迭代速度，降低了升级成本。一个Dev（SecOps团队符合“双披萨饼规模”，如果发现某个服务单靠一个“双披萨饼团队”已经很难维持高质量快速迭代时，就对服务进行拆分，使之可以被多个“双披萨饼团队”单独维护。HIOS的工程师与KA客户的工程师混合组队，快速实现业务迭代与服务交付。

酒店产业的数字化转型才刚起步，未来还有很多挑战要克服，希望能够与更多的同行进行合作交流，为产业的发展做出更大的努力。