GSK首席架构师徐洋

大家下午好，很荣幸有机会再次来到这个论坛给大家分享一我个人的一些探索。

架构视角

今天主要介绍一下，从架构上来看云计算对MCM以及其他一些创新的帮助。在2013年讨论架构的时候，当时很多公司还没有专职的架构人员，到2014、2015年的时候，就有很多企业开始招聘架构方面的人员了，很多人今天在企业里已经承担起架构管理的工作。

我再次和大家分享的就是，当CIO想要在企业建立这样的团队或者人员的时候，他的着眼点应该是着眼于以下几个方面：

首先是为企业IT的中长期战略目标服务，这点特别强调一下，中长期的战略目标不是短期的战略目标。短期的战略目标指的是，比如有一个系统要迁移，具体的问题去解决。中长期的战略目标可能是要考虑到五年甚至更长的战略。

技术、解决方案、产品中立这点非常非常重要。所有IT人都会存在这样的缺陷，就是他一定是沿着某一个技术路线成长起来的，成长起来之后，当在架构的领域，在更大的一个层面上，需要把握些技术方向的时候，一种可能是他对自己熟悉的技术非常喜欢。还有一种可能是他对自己熟悉的技术不足的方面非常的了解也非常排斥，所以我在这边特别的强调，作为企业的架构人员，必须要保持技术的中立，技术上没有对错，只有最合适的，架构人员要秉承技术中立这样一个理念。

关注规则的制定。指大量的项目大量的游戏规则要去制定，不只是关注在某一个项目上去解决。

关注技术前瞻性。我们现在说云、大数据、IT、互联网这些都是比较先进的技术，怎样使这些先进的技术以一个合适的方式和企业的业务目标结合起来，创造商业价值，这是架构师应该去关注的东西。

关注技术的商业价值，这个就不多说了。

External Focus。在整个互联网，在关注消费者行为和消费者洞察角度这方面我们必须向快消品行业去学习，他们在这方面做的比我们早的非常多，所以External Focus，是要跳出我们的行业去看其他行业的一些做法。

MCM vs 传统IT交付物

先跟大家分享一下MCM和传统IT交付物的区别，我相信大家在自己的单位会遇到这样的情况，MCM团队越来越多的尝试在IT领域去开发一些东西。那么，是谁在帮助MCM呢？有可能是内部资源也有可能是外部的agency，那么外部的agency公司和我们今天IT所拥有的供应商区别是什么？他们在做的交付物和我们IT在做的交付物区别又是什么？

其实今天对于我们制药公司的创新而言，MCM已经是创新的很小很小的一块，当我们看到某友商的3D战略已经很明显是价值链和产业链的整个创新，不只是市场marketing这一个领域。如果是这样的话，未来会越来越多遇到需要我们明确的地方，就是说，传统的IT交付物和MCM的交付物有什么样的区别，包括可穿戴设备这些，不只是解决方案，而是带着硬件的解决方案引入到我们企业的IT领域时又会是什么样的一个情况？

跟大家简单的介绍一下，这是我们今年的思考：

监管

首先第一点是监管，传统的IT交付物在我们的局域网里都不涉及到监管的问题，但是一旦要放在互联网上的时候，这个监管的问题就会出现了。

比如最简单的做网站要做ICP备案。除了ICP备案，如果要在互联网上发布药品信息和健康类信息，还有互联网药品信息服务证书和互联网健康信息服务证书，处方药业务信息发布需要申请药品信息的、OTC做健康信息的这些证书和申请流程以及容易出问题的地方，大家都要了解。了解这些信息之后，当我们在国内选择云技术合作伙伴的时候，需要特殊考核的就是这些合作伙伴至少具备这些能力，来帮助我们满足监管这些方面的要求。

负载

除了监管之外，还有负载。这是很有意思的话题，在我们企业传统的交付物里面，谈到所有的系统，有一个大的考虑因素是多少个活跃用户，比如说面对我们内部的员工，基本上它不会超过我们员工的总数。

如果在互联网的交付环境下，尤其是MCM，还举网站的例子，这个网站的负载是完全不可预计的，尤其是在涉及到电商的情况下，尤其是电商在搞一些促销的情况下，负载的波动情况会非常明显。就是在MCM的情况下，网站或者交付物的负载将不再是传统的模式完全可以预计、完全可以控制的了。

风险

在传统的IT交付物内网里有防火墙，可以很安全平稳的保护我们的系统，基本上最大的风险就U盘和传染病毒，除了这些以外其他的风险很少遇到。如果走向MCM，走向互联网之后， 类似DDoS攻击这样的互联网风险就来了。遇到这些问题应该怎样处理？其实这些知识在传统的制药公司内部IT团队里是不具备的，但我们需要去学习，因为我们面临这样的挑战：风险更大大了，但是可用性要求却提高了。

举个简单的例子，原来在企业内部维护任何一个系统，顺理成章的可以在维护窗口时间中关机重启。但如果是互联网业务的话，这绝对不可以的。一旦走向互联网，面临的挑战和风险会越来越多，面临可用性的要求却会越来越高。风险包括DDoS攻击、拖库（数据库被攻击的时候把整个库拿走）等等。其实在技术上这些都有比较好的防范手段，但是我们没做，一是没人知道会存在这个风险；二是管理不到位；三是没提前做技术上的储备和防范。结果导致这些事件频繁的发生。

生态系统

过往大家做业务系统最多考虑的就是和我们自己的系统做接口就可以了，因为都是自己的系统，相对来说双方的合作比较平等，技术规范自己也可以很好地定义。

但是如果我们做一个互联网的业务，一个MCM的业务或者其他的创新业务的时候，就会发展我们的生态系统的构建会变得非常复杂，要和各式各样的合作伙伴，硬件的、软件的解决方案的供应商去合作。但是在谈判或者商业合作的过程中，很多不再是处于一个对等的地位，像BAT这些大的合作伙伴，如果要跟他们去做合作的话，大家必须承认，我们很难去改变他，必须按照他已经规划好的技术规范和技术规则来做。

生态系统可能对于我们今天绝大多数制药公司来说还不是特别大的挑战，但是有一天当我们需要构建自己的生态系统时，问题就会变得非常突出。

前端适配

这个完全是灾难性的，如果我们做了APP的话，IOS至少要两个版本，iPhone和iPad的，iPad可能还需要三个版本需要适配，有iPad mini的、普通iPad和iPad Pro。如果是安卓，据2015年的统计，安卓大概有22种屏幕尺寸比例。除了和移动设备这些相关的适配，还有一个就是和微信的适配，而且微信接口每次升级的时候提前告知期都很短，这使得前端适配的挑战异常艰巨，而前端适配又是随着目标用户的使用习惯和偏好在不断偏移的。

以前可能我们会觉得做一个APP就已经和不错了，但是这几年随着微信的不断发展，微信的公众账号、微信的企业号，可能很快会出现微信的应用号等的发展，前端适配的挑战会越来越大。

费用和费用投入的百分比

这块也会涉及到传统IT思路的变迁，在传统IT谈到做一个开发IT交付物的时候会有三块费用：设计、开发和维护。但如果要做一个MCM的交付物或者和传统IT相关的创新的交付物的话，除了刚才提到的三大块费用之外，还有一块非常重要的费用就是推广，除非我们不为结果负责，否则我们就必然考虑到这些交付物的推广费用。如果没有推广的费用，可以想象大家辛辛苦苦做的APP放在市场里或者APP Store里面没有人下载的情形。所以在费用投入这块，企业的IT要扭转一下传统费用的结构，增加应用推广，而且要给与非常大的比例，否则大家很有可能在MCM或者IT创新上由于没有办法落地，导致投入打水漂。

技术实现 vs 用户体验

作为IT人士很早一直以来都非常关注的事情就是技术实现，而且非常乐于去跟用户讲我们经过某某优化之后，使得某一套SQL语句的查询时间由原来的35毫秒缩短到16毫秒，这是我们原来比较喜欢的沟通方式。

但在MCM甚至在更多的创新领域里，用户体验才是最能打动用户的地方。传统IT人员的结构里，都是中规中矩的技术出身或者管理出身的，在用户体验方面没有非常专业的人士。用户体验方面专业的人士会有一些特征：第一，非常感性。他可能根本没有办法跟你解释这个东西为什么不好，但是他会告诉你这个东西不行，这和我们传统的IT管理人员不一样的；第二，他对技术细节，技术实践这方面不关注，他只是觉得这个东西应该被做出来，至于怎么被做出来，应该有其他人来帮助他，这和传统的IT人也不太一样；第三，对用户体验追求的人对自己用户体验观点的认可度非常高。表现在当他跟业务部门和其他IT部门做沟通的时候存在障碍、表现的非常独断，他会觉得你们这些观点不可以被他和最终用户来接受。如果大家发现自己的IT团队里存在这样的人，而且大家在MCM或者其他的创新领域里面存在这样一些业务需求情况下，可以刻意把这些人培养成在用户体验方面能够给你提供贡献的团队成员。

IT供应商 vs Digital Agency

IT的供应商和Digital Agency的区别，这些是我们去年花的一些时间去考虑的，因为在实际的工作中我们的确遇到过这样的情况，同样做一个东西，为什么有的人报的价格是另外一些人的三到五倍，怎么样去区分这两类？

因为在企业里我们的Marketing或者MCM的部门会有他们的一些预算，站在采购部、财务部的角度来讲，同样做一个APP，为什么IT的供应商这么便宜，Digital Agency要这么贵呢？

大概这个区别会是这样的：IT的供应商比较关注业务领域和IT知识，Digital的供应商比较关注行业方面的知识；IT的供应商会关注怎么样去开发一个交付的平台，Digital供应商会关注怎么样去开发一个内容开发一个服务；工作方法上，IT的供应商会有一套非常完整的IT管理流程，Digital供应商会倾向于业务流程，但不是特别关注安全风险，而是注重内容和数字化的服务；经过很长时间的磨合，IT供应商基本上会遵从我们IT的一些规则，Digital供应商在这方面的关注度就不是那么高；在整个项目交付之后，IT的供应商最后会有一个支持模式，在这个支持模式里面，会把又开发的知识以文档的方式完整地转移给交付的这家公司；但Digital供应商会觉得这是他的资产，不可以转交。万幸的是，在我们这个行业里面，IP共享已经是非常普遍的话题，大家在法律允许的范围内已经在解决这个问题了。最后Cost of Ownership很明显IT的供应商不便宜，但Digital供应商更贵。

入口 & 核心IP

什么是入口？笔记本电脑是入口，iPad的也是入口，控制这些入口。比如通过控制iPad上MDM的软件，就是移动设备管理软件，就可以决定什么样的软件可以安装在这个iPad上，什么样的软件不可以，那我们就控制了在平台上去发布应用的权利。

哪些是核心IP？域名是核心IP，域名还可以转让。以前我们的确发生过这种情况，有市场部的同仁请第三方的供应商注册域名，然后把网站搭起来，结果域名就控制在第三方的手里面。微信的公众号，目前腾讯尚未有明确的流程定义公众账号的所有权如何转移。

所以站在企业IT的角度来讲，首先要控制住入口，企业的核心IT入口；其次要控制住核心IP资产，哪些是核心的IP资产？域名和微信号这样的都属于核心的IP资产。

典型云架构

如果今天能在企业内部做一个应用产生这样的架构：前端一台服务器，后端一台数据库，大家都以为这样蛮好的，但问题是，如果把它搬到互联网的话，比如有一天做促销，这样的架构是完全不能承受暴增的业务量的，一旦数据库出了问题，整个链条就都完了。这也是为什么我们今天要考虑云计算的原因，云计算能够给我们带来什么样的好处呢？

我本身对私有云非常反对的，我更坚信在中国绝大多数制药企业根本是没有私有云的需求的，大量企业在私有云上所有的投资，在5年之内必然得到非常低的回报而且会觉得钱完全浪费了。大家尝试完公有云之后就会知道公有云和私有云完全不一样，那么我们在公有云的平台上希望获得什么样的能力？弹性、解耦和高可用，我们就关注一下这些方面：

这是我在AWS官网上复制下来的一个非常典型的云架构。在云上面，前端HTTPS请求过来（在今天，全站HTTPS已经完全不是问题了），一般说来全站HTTPS大概会带来服务器20%-30%的性能损失，怎么办？采用一个叫SSL Terminator技术，把SSL的负载压在负载均衡器上，这么做还有一个好处就是，SSL数字证书是我们非常宝贵的IP资产，如果放在服务器上面，有人会把它拿走，产生一定的风险。当采用SSL Terminator技术的时候，SSL的数字证书都部署在负载均衡器上面，负载均衡器是无法直接访问的，所以这样的话SSL数字证书就被保护了。在负载均衡器后面会放一组支持Auto Scale的解耦应用服务器，它的规模会随着业务的增长不断地收缩，扩大缩小都可以。再后面是数据库，在数据库这边通过一个概念叫跨可用区副本，什么叫可用区呢？每个可用区大概有两到三个机房，每个机房大概两到三万台服务器，每个可用区可以满足同城灾备的理念，一个可用区的数据库down掉之后，另外一个可以衔接起来，切换的时间大概在5分钟左右，在这5分钟之后正常业务交易不受影响。TDE（Transparent Data Encryption）透明数据加密，应用TDE的技术，除了会带来数据库性能损失这一缺点之外，前端的业务应用程序一个字都不需要修改，加密对应用程序而言完全透明，唯一需要大家注意的就是，TDE的技术在现在主流的关系型数据库上虽然都支持，但在不同型号上做的支持是不一样的，像Oracle的要购买企业版的许可才可以等等。在这里，业务和数据库的东西都没有暴露在互联网上面，如果需要访问互联网上资源的话，就需要一个NAT Instance来转换，这样进的流量和出的流量都会通过唯一的端口，可以更好的控制。我们所说的弹性就是在中间这块，通过Auto Scale的模式满足条件，比如两台CPU，一个CPU都达到90%了，就会启动另一个服务器实例来处理业务，自动安装好所有需要安装的程序并且开始承接负载均衡器分配的业务交易，这就是所谓的解耦和弹性可负载。刚才说不同可用区里面，哪怕是一个机房正常的光纤断掉了，业务也不会受影响。

国内不同的云服务商，大家对物理安全这块的态度还是不太一样的，比如某些公有云服务商坚持不肯公布自己机房的地址，坚称自己机房外面不会写上比如XX数据中心这样的字眼。但在前段时间，在国内某云计算服务商的一个宣传材料上看到该服务商所谓的下一代数据中心的宣传照片，包括数据中心大楼的非常有识别特征的照片，大家可以看到大家在这些领域的思考是完全不一样的。

“云端”其它需要考虑的因素

在“云端”其它需要考虑的因素，第一个是软件license，计算总体的成本，大家要在一定程度上把软件license考虑上去；计费方式，云计算一个非常值得探讨的地方就是它的计费方式非常复杂，比如服务器是按小时计费、进出的网络流量是按照流量计费、还有些服务是按照使用的次数去计费等等，万幸是我们可以在互联网找到很多工具来帮助你做些评估；可用性、RTO、RPO不用做过多的解释；压力测试，一定要做压力测试否则根本不知道会发生什么样的情况，也不知道云计算的特性是什么，比如在负载均衡器后面放四台大的服务器和放八台小的机器，哪一个性能更好？可能在物理机房里，四台大的服务器效果更好，但在云计算里面，八台小的服务器可能性能会更好。穿透测试及测试报告管理也是必须要做的，而且绝对不可以泄露给任何的第三方。

DDoS策略

“常态”和异常感知；3层、4层DDoS攻击；7层DDoS攻击 - WAF三明治设计；预案 - 尤其是网络带宽的支持；云WAF - 洗流量等这些，这里为在座的CIO需要找对合适的技术人员来解决这些风险提供一些线索。

架构的设计不是一蹴而就的，架构是随着技术和业务的发展不断演进的。所以大家一开始的时候不一定要追求非常高非常稳定的架构目标。当业务系统的并发用户（不是注册用户也不是活跃用户）低于1000的情况下一般不需要考虑特殊的架构设计，单纯通过硬件和软件的升级优化就可以来实现这样一个业务负载目标，因此建议大家首先需要关注的是技术能够创造的商业价值和如何才能支持业务目标。

Beyond MCM

云历程大家准备好了没有？其实不只是技术方面，还有人员储备，创新理念，互联网精神等各个方面。

其实我们今天再谈MCM还是有一点弱，我个人比较推崇的制药行业其它友商的价值链创新理念，在我们这个行业创新已经覆盖到了产业链和价值链的每一个领域。在制药行业之外，大家都希望做闭环，所以今天我们今天谈的云技术可能更多的会助力我们着眼于未来将要面对的创新的业务挑战，而不只是今天以内容和渠道为主的MCM创新的挑战。

结束语

以上是我今天要分享的，我本身是做技术出身的，而且对云计算非常感兴趣，本人非常愿意和IT同仁在技术上做分享，这也是我们IT行业典型做互联网分享的精神。希望能够和大家做更深层次的讨论，谢谢大家！