航司数字化转型的重点投放及IT要素（1）
前言
航司的数字化转型在出色的领导团队及明智的战略方针和持久的投入下，大部分关键工作均会落到现在的营销委等相关职能部门，即电商及旅客服务团队，关键是电商的中后台。因为其实最终直达C端的渠道，和拥有真正内容的引擎环节，就是在此。
会有些人认为，航司的数字化转型重点在于飞行运行等系统及团队，但是试想任何一个数字化转型的IT特点，很多都不能适用。例如快速敏捷的迭代，为了运行安全，另外业务的深入及壁垒，航司的飞行运控等系统不能按照敏捷的方式构建及乃至试错。顶多只能到迭代开发。而且其不能最终掌握C端的关键数据，乃至不能拥有任何直达C端的触点。再例，飞行运行中使用DevOps，也是没有太大意义的，因为其根本、也不太可能出现大规模及频繁的发布，虽然运维和监控等领域，涉及大量和较为深入的DevOps，但是其跟数字化转型的一些期望还是有悖。即使有没有数字化转型，其还是期望更多的“自动化”诉求的实现。所以航司生产领域，例如飞行运行，要做的是“自动化”，以提高生产力。但是航司营销等部门，要做的是发现价值和增加价值，以提高生存空间。
投放重点
a) 以实现数字化和品牌化航司为目标的个性化之路。
b) 以数字化革新平台支撑的航司战略蓝图。
c) 多维度革新及融合，来应对全新的挑战。
d) 切合实际的“人/财/物/时间”落地方案。
关注点的转变
传统的航司企业IT以数据中心、普遍开发、烟囱式架构，IT开销，过程驱动，运营为其特质，关心业务及系统的自动化、操作及功能的独立、关注数据模型，数据的记录、预计的变化，强调服务交付，集中的IT等等。
数字化的航司需要大力利用云计算，敏捷及DevOps，生态系统理念，IT作为新的收益来源，以数据驱动，试错式迭代来实现业务的敏捷化，无边界的协同，关注业务领域，持续中持续，数字化体验，分散解耦的IT等等。为了实现从“航母型航司”转变为“品牌化航司”，其将采取4个关键战略，推动不同于任何航司的个性化创新转型之路：
Ø
尽量稳定核心系统和核心业务的前提下逐步转型的迭代策略。
Ø
紧跟业界及市场，尤其IT领域的技术前沿，且认清自身特质，去粗存精的、辩证的将新技术新理念融合于自身体系之内融合策略。
Ø
取人之长补己之短的合作伙伴共赢策略。
Ø
领导行业的前瞻战略。
人+财+物+时间的融合
成功的产品在于好的项目管理，优秀的项目管理关注“人/财/物/时间”。将数字化转型作为一个全局协同的项目来看待，则需要首先打好“人/财/物/时间”的基础。
Ø
在具有高凝聚力和高执行力的团队的前提下，提升其敏捷性和数字化能力，强化复合型人才建设，以期打好“人”的动力。
Ø
“互联网+”及“数据+”的核心价值是数据，在辩证的学习国内互联网企业的相关经验下，逐步将前沿数据处理及存储的技术与南航实绩相融合，创新及安全构建“财”的基础。
Ø
产品的精髓在于理念，理念的支撑在于架构。基于全局性及前瞻性的架构体系建设思维，通过LEGO式“微模块”化面向领域构建，锤炼工欲善其事必先利其器的“物”之利器。
Ø
时间就是生命，将有限资源投放在关键环节。通过融合性且针对性的技术架构革新，以空间、经验、维度、智能换时间，以强大及弹性的数字化计算能力换取“时间”的生命。
从而实现航司电商等相关领域的关键特质：个性化服务，菜单服务，全渠道服务。
IT因素
那对于航司的数字化转型，其关键的几个IT方面的因素，是需要航司结合自身条件和规划，逐步建立从战略到投放的长久方案，并构建专业性的团队逐步推进。最关键的构建一个团结一致、数据过硬、业务精通、思维开拓、动作敏捷的团队，尤其是电商中后台团队。
DevOps
航司电商虽然有“国有”的性质，但是在现在的互联网经济爆发及激烈的全球化市场竞争之下，其必须具备互联网企业的技能和开发及交付能力，尤其是从开发到运维的全面技术及规范融合敏捷方案。不仅仅是传统的编译、打包、发布、自动化测试，更关键的后续的自动乃至智能的运维，同时将各类新的IT技术有机的糅合进入日常的开发和运维环节，永远保持一颗年轻的心。
同时为后续另外一个关键因素-“云计算”打下良好的基础。
1) 没有边界的高价值存在
a) 应用和系统永远是建设在基础设施及平台服务之上的。
b) 从立项开始，到设计及实施，一定要考虑资源的现状，人员的能力，及日后运维的全部依赖因素。
c) 一个高效，全面，全栈，敏捷，专家/有经验的软硬件资源平台，管理平台，工具箱，运维包，以及相关规范手册终将节省大量的人财物时间，为企业数字化转型提供最有力的支持。
d) 如何充分利用已有资源和职能范围，提升价值/创造价值/改造价值，尤为重要。
2) PreDev ► Dev ► Data ► AI Ops
a) 新传统应用及系统开发的IT技术日新月异，同时开源化和轻量级等的使用，增加IT运维的压力。
b) DevOps要求的自动化/工具化/敏捷化还没有全部实现，企业数字化转型有提出更高的要求。
c) 大数据和数据智能的几何级数的增长，更需要用工具代替人，用全新的思维和方法醍醐灌顶。
d) 更大挑战和要求还在AI，通过算法替代固定的模式和流程，从而上升到更高层次的“自动化”。
3) 从DevOps到DataOps
a) DevOps侧重于：工具，自动化，开发及运维团队，运维是系统设计的一部分，协同。
b) DataOps侧重于：数据，可视化，可追踪，专业工具，数据分析工程师。
c) DevOps是与企业数字化转型，IT敏捷及迭代开发等相关联的。
d) DataOps是与专门数据处理相关的体系。
注：航司一定要在现有的自动化生产力提升的诉求下，构建好DevOps，并为DataOps的实现提供高价值的DevOps实现。因为航司电商等领域的核心价值是数据。大量的经验和反馈均证明，航司产品的优劣，内容的丰贫，产品的好坏，数据起到了关键作用。
云计算
云计算不是简单的使用企业内部冗余或高效的使用原来企业内部的各类物理机/实体机上构建的虚拟机，或者内部的私有云等基于虚拟化的私有基础设施平台，而是真正在公有云上，例如Azure，AWS，Aliyun等上面，使用其IaaS、PaaS及SaaS等服务，或者乃至BaaS（Backend as a Service）。充分享用其弹性的黑箱的各类服务。使用RDS，不必关心其承载的虚拟环境及操作系统，也不必关心是否与其他云服务消费者Share某些内部资源。只需要关心我需要怎样的资源，其他有云服务提供商及平台来保障隔离和抗干扰等问题。
虚拟化与容器化
很多航司还停留在虚拟化的内网In-House部署方式。容器化方式部署，及日常开发等，还遥遥无期。但是我们也慢慢看到一些好的航司案例，再转型和逐步投入一些云服务提供商的产品到自己日常开发、产品上线及运行等环节，乃至一些核心业务功能。
但是航司一定要拥抱这个方面，从容器化开始，让自己的开发真正赶得上时代潮流，让自己的运维能高效起来。因为航司永远不是以高质量IT运维为目标的公司及团队实体，所以一句话：让能人做它擅长的事情，自己做自己高价值的事情。
迁移方法论
技术的强大工具生产力及云服务提供商的优质服务摆在哪里，但是没有优秀的迁移方案和投放设计，只能是简单的系统重新部署，设置更多的航司只能使用到云服务提供商的ECS产品层次。其实就是虚拟化的IaaS层次。真正的云计算，不仅仅是IaaS，还要PaaS，充分使用云服务提供商的平台化能力；然而真正高效和高价值的使用云计算提供商的能力，是SaaS的方式。
所以一个有效的迁移方法论，关注的如何评估自身现有情况，定义行之有效的行动方案，然后再执行、迭代、优化、萃取。
迭代
敏捷及迭代是比较流行的对于开发管理及项目交付的理念，但是其本质区别在哪里，为什么之前几年敏捷开发如火如荼。但近几年又提出或流行迭代开发了，就好像埃森哲一些之前咨询交付服务企业，也不提敏捷开发了？
差别
正如如下图示所述，其差别在于拆分交付的认为的力度和任务交付的并行要求。同时也来自中西方文化的差异，往往老外的敏捷跑的好，中国人最好还是老老实实跑迭代更有价值。
那真要区分敏捷和迭代的差别，则就好比如下的例子所解释：
a) 看你手下有哪些”动物“，是猪多一些，还是有一批狼，还是狮子多一些。
b) 你的交付诉求是怎样造一个人。
方法论
a) 在总体规划和HLSD的基础上定义整体交付蓝图和阶段性目标。
b) 在人，及团队的基础上，明确人力投入能力。
c) 以可分割的交付目标及交付物即时可用的诉求，定义迭代的交付物。从而定义交付计划。
d) 迭代中包含敏捷，但是迭代更多的像一个瀑布开发模式的“缩小版”。
数据处理
数据的价值不言而喻，但是如何产生价值和让数据能够升值不谈，如何将数据保存好，都是一个很难回答和实现的任务。
阶段性
有人会说EDW（Enterprise Data Warehouse）和维度建模做好，问题就解决了。但是其忽略了一系列关键问题：数据是流动的，数据的接入是实时的，数据是多源及异构的，数据的使用更是实时的。所以不管航司是由有EDW或Bigdata平台，关键是让数据的处理流动起来，动态起来，实时起来；阶段性更强。
管道化
未来的数据需要在实时的流动过程中即时被处理，所以数据流及流式处理必须有，按照pipeline的方式逐步处理数据并关心最后的outbound目标。
方法论
做好数据处理，不是简单工具的使用，更关键的是梳理即有和未来增加的数据情况，从数据规范的角度增强数据流式处理能力。
集成平台
常规的集成主要抽象和整理为数据的集成和业务的集成。
但是真正的集成平台，是能够让电商及相关部门能够更高效控制自己的能力建设，将各类合作伙伴的产品动态插拔在航司的电商平台上。
航司数字化转型的重点投放及IT要素 (2)
前言
如前篇所述，航司的数字化转型是一个综合的体系工程，不能简单的通过增加销售量来拉动，也不能简单的通过提升IT技术和管理水平。必须有的放矢的投放在几个关键IT环节。DevOps、云计算、迭代、数据处理、集成平台是前篇介绍的思路。下面就针对另外几个IT因素阐述一下个人理解。
IT因素
那对于航司的数字化转型，其关键的几个IT方面的因素，是需要航司结合自身条件和规划，逐步建立从战略到投放的长久方案，并构建专业性的团队逐步推进。最关键的构建一个团结一致、数据过硬、业务精通、思维开拓、动作敏捷的团队，尤其是电商中后台团队。
精准
精准营销，千人千面，旅客个性化，A' la carte等等，都是要构建针对单一个人的产品和服务。但是谈何容易。
a) 数据
最关键的是构建数据，基于人的Single Customer View，以及相应的Behavior Data。航司往往要么没有还没有起步，要么局限于数据来源。数据又不能买卖，大量的旅客数据来源于常旅客、电商会员、高质量的乘机记录或销售信息、电子客票、预订信息、或再来自中航信的离港等数据。有些航司也在开始考虑收集电商直销平台的互联网数据。但是这些只能对高频和忠诚用户，有更好的收集效果。但是对于航司扩展客户群体，吸引那些低频客户或潜在客户还是微乎其微。所以我接触民航总局的时候，就曾经考虑，是否真正有一个全国性的旅客信息平台，甚至中航信的数据是否真正能发挥价值。
b) 来自于资深行业专家的模型/算法
数据的缺失，是可以通过特征工程和数学模型乃至特定的算法去弥补的。但是一定有行业的背景的资深人士，而不是BAT等IT领域的团队。最近接触过Baidu的AI团队。确实其能够提供资深的工程师、强大的技术支撑等，但是关键的是行业业务的领悟和多年的掌握。
所以一定要有资深的行业专家来参与，利用IT公司的计算支撑，协同实现一些突破。
同时航司的参与也无与伦比的重要，谁能比其自己更懂自己的产品和客户呢？看过很多案例，自己也亲身经历过几个不成功的案例。行业专家及我们确实想的很超前，但是投放到航司等领域，其就是缺乏说服力和生产力，甚至跟现实脱节太多。
c) 元数据
这是此主题的关键，精准在与航司内部对于数据的描述的精准和一致。为了后续敏捷的实现各类对接、系统融合及编排、内部更顺滑的“流转”。其关键是必须制定一套规范性的数据模型，数据契约。
往往只有生产环节、系统、大后台，才去考虑Metadata。但是航司的营销领域，我认为是必须构建其必须贯彻执行的。从数据的命名、类型、精度、长度、Mandatory/Optional、等等构建完整的数据字典、数据规范模型、基础数据契约、SimpleType、ComplexType。即一整套基于XSD的Schema契约规范。】
各个航司领导和产品技术团队核心人员，其实都不敢拍着胸脯说：我们下面的团队，有一整套符合英文标准命名规范，层层一致，里外一体的数字契约和数据字典。我见过太多让人“蛋疼”的数据契约命名和使用。而且大量过时和不匹配的接口文档。而且随着大量低水平外包人员的引入，那些字段命名和使用，会让我这样有洁癖的人自杀很多次。
正如AIDM（Airline Industry Data Model）及航司电商熟之不能再熟的NDC，其都是在规范数据契约。再或者Sabre及LH的Open API等，其都是在自身业务的基础上，抽象出一整套数据契约规范。同时在建设新系统，尤其Open API的时期，将这套元数据贯彻到中后台的各个环节。
近期正在给一个大航司建设类似的功能，所以技术细节不便公开。但是此流程必须从XSD出发，从DTO、Domain Entity（POJO/POCO）等、乃至DAO、Data Model逐级认真贯彻。这个是航司企业的关键数字资产的基础。更是让后人能够收益的关键。
微模块
大家大量听说“微服务”/Microservices，同时也听过SOA。但是何为微模块？
a) LEGO积木
我们的系统，尤其是电商的系统，不是必须全部要服务化，把SOA力度增强后转变为Microservices，这样要求极大的投入和对于设计的极高要求。但是也不能置之不理，让一个系统一个系统的罗列在哪里，最后变成end-to-end的系统对接网络。
所以最合适的方式，就是将自身的业务、系统、应用，按照水平和垂直的两种不同思路，以FR和NFR的特征，拆解为各个能够独立运转“自运行” & “自维持”的微小模块。可以是Microservices的表现，也可以是非服务的形态，乃至Jar/Dll方式。
航司电商，尤其是营销口，可以充分利用这些模块化的LEGO积木，组建全新的业务形态和流转。重新建一所漂亮的房子自然美好，但是投入精力和未来的变化是不可预知的。业务LEGO的房子有些棱角，但是其结构是坚固的（由于你有一致的数据契约，精准的接口规范），业务也是完整的。更难能可贵的是随时可以打散为可复用的模块搭建你新的房子。
b) Microservices
微服务不是简单的RESTful Service，也不就是JSON。其是代表一整套架构设计思路。更关键的是，且也必须有契约，有规范，有体系。
航司要推进直销，采用NDC，关键是中后台要有一套强而有力的模块化的服务接口。这个时候微服务就是最好的技术实现方案和体系设计思路。同时对于航司推进Open API也是最好的技术实现。从Edge Service到Internal Service，从API Gateway到Registration中心，从Configuration到Distribution，从熔断到链路跟踪，乃至边缘计算等等，都是更高效和轻量化的服务技术实现。更关键的必须要将数据契约，服务企业，操作契约，也就是SOAP Web Service的ABC的概念投放到RESTful Service。这个不是倒退，而是人们的思索及改进。将yml等为基础的Swagger等有机的融入体系建设中，更尤其是技术架构开发规范中，势在必行。更是电商中后台的一个关键任务。
c) DDD
https://en.wikipedia.org/wiki/Domain-driven_design
https://baike.baidu.com/item/DDD/3539802
这里不介绍这个概念了，但是其是对于Microservices设计及开发的一个关键概念。要想构建好航司的核心微模块化能力，必须从业务上把控，用Domain-Driven Design的设计思维去构建服务。“Monolithic”化业务、数据和实现。
但是这正是航司人才储备比较缺少的一个环节，没有资深的行业背景的架构师，尤其是企业架构师，很难构建一个体系化的微服务体系和平台。单纯的堆积技术，是徒劳的。
“花非花、雾非雾”
技术是为了服务于业务的，但是很多技术的出现是单纯为了革新而产生的。那如何高效精准的使用技术，服务于日常工作，服务于产品建设，服务于数字化转型。则必须Open Mind。
举个例子：之前一个德国厂商有大量后台作业需要业务流程编排，而且是必须的，也是业务要求及技术无法规避的。那德国厂商的建议是一系列Workload Scheduling & Distribution产品，例如UC4等。这些产品软件确实好，不考虑价格的化，能够极大提升生产力。但是在有限的经费和人员素质的前提下，我的方案是使用Jenkins。当我说出Jenkins的时候，老外们的下巴已经掉在地上了，眼睛圆圆的呆滞了大几秒钟。但是回过神来的时候，他们的回复是：Brilliant！
所以每个技术、框架、产品等，都是工具，人不能沦为工具的奴隶，要主宰工具。所以要深究其解决怎样的问题，抽象其解决问题的思路。而不是看他们的代码，看他们怎么实现的（这是大量应用开发工程师会干的一个事情，我不认为不对，但是有多少人能从看他们的代码，学到或掌握些什么呢）。还不如多体会体会其思路，好好“用”好它们，毕竟他们是工具，是被用来“用”的，而不是“拆”的。拥抱技术，将会面对更多的新颖的工具，以及日新月异的革新和冲击，对于“中年油腻”的人们，重点是思路和抽象。
对于航司电商等，其一定要Open Mind，用开发的心态去接触新技术，去摸索和分析它，去用心抽象它，用更开放的思路去融合它，善用它。
总结
航司的数字化转型大量取决于营销等部门，更是“吃力不露脸”的电商中后台的必须投入。如何将人财物及时间有机的融合在一起，构建高价值及高效的核心动力引擎，及电商中后台引擎能力的提升，将是这个长期战略规划成功的一个重点。让航司尤其电商中后台，拥抱新技术，接受新理念，必有开放的思维。真真正正的将如上IT因素解决好。
航司的DevOps & DataOps & AIOps
前言
数字化转型大潮中，常常说到DevOps，但是其并不是数字化转型所特有的。从一个高度及敏捷的研发团队的角度，其是必要的技术组成部分，甚至不在于是否用不用敏捷。并随着大数据的特有应用，衍生出DataOps；同时由于互联网相关应用等的大规模分布式的使用，及虚拟化、容器化等等的海量集群的应用，AIOps也被冠名了。
小运维与大运维
a. 统一及集中的部门和团队的成立，就是为了提供集中/一致/协同的管理支持，提高专业化水平。
b. 但是其不能永远站在后面，被动的接受服务请求。
c. 其专业性和资源集中性要渗透到立项，开发，运维等的全生命周期中，协同应用及系统建设和后续工作。
d. 不管是自己内部资源，还是外部资源，第三方服务及产品，团队应是组织与基础设施及平台服务的唯一对接中心。
没有边界的高价值存在
a. 应用和系统永远是建设在基础设施及平台服务之上的。
b. 从立项开始，到设计及实施，一定要考虑资源的现状，人员的能力，及日后运维的全部依赖因素。
c. 一个高效，全面，全栈，敏捷，专家/有经验的软硬件资源平台，管理平台，工具箱，运维包，以及相关规范手册终将节省大量的人财物时间，为企业数字化转型提供最有力的支持。
d. 如何充分利用已有资源和职能范围，提升价值/创造价值/改造价值，尤为重要。
PreDev ► Dev ► Data ► AI Ops
a. 新传统应用及系统开发的IT技术日新月异，同时开源化和轻量级等的使用，增加IT运维的压力。
b. DevOps要求的自动化/工具化/敏捷化还没有全部实现，企业数字化转型有提出更高的要求。
c. 大数据和数据智能的几何级数的增长，更需要用工具代替人，用全新的思维和方法醍醐灌顶。
d. 更大挑战和要求还在AI，通过算法替代固定的模式和流程，从而上升到更高层次的“自动化”。
从DevOps到DataOps
a. DevOps侧重于：工具，自动化，开发及运维团队，运维是系统设计的一部分，协同。
b. DataOps侧重于：数据，可视化，可追踪，专业工具，数据分析工程师。
c. DevOps是与企业数字化转型，IT敏捷及迭代开发等相关联的。
d. DataOps是与专门数据处理相关的体系。
DevOps
概述
a. 基于过往大型企业项目，国外航司及IT服务公司经验，运维是一个技术活，需要专业团队。
b. 往往是多个角色团队的协同。
c. 并超越单纯硬件及网络的运维支持，上升到企业级及通用的服务化支持。
“开发平台即服务”与应用/系统开发团队协同
IaaS及PaaS，和Microservice等的出现，要求IT基础设施和服务，一定要能够支持。
development Platform as a Service （dPaaS）则普遍变为一种潜在IT运维团队的增值和高价值服务，并牵引开发向规范化和敏捷化发展。
后台作业可视化，自动化，管理工具化
以LH的Customer Loyalty为例，航司大量的日常工作将集中在后台作业及批处理文件的处理上。
在开发完毕交付的作业任务的管理，不仅仅只是属于作业实例的驱动，更关键是一整套任务链的协同。
分布式集中日志及运维服务升值
结合CO/UA及DL交付经验，一整套集中的日志系统，将会对运维和系统管理提供强有力的支持。
企业级监控框架及平台
a. 根据若干航司的案例，人财物时间的投入，将是后续运维精力优化的关键，尤其是管理方面。
b. 但是必须根据项目范围，系统规模，以及NFR需求关注点，指定针对性的监控目标，而不是一应俱全的满足4个层面。
c. 更关键的是某些层面，譬如连通性及系统效能等监控属于统一的职能范围和管理主体。
虚拟化容器化云化运维
