酷澎
数据驱动决策是酷澎核心企业文化，数据工程师和数据科学家遍布酷澎不同部门。举凡美术设计、介面设计、行销策略以及其他业务环节，酷澎许多决策会利用数据来验证最佳做法。他们最常用的验证方法是A/B测试，酷澎App中，每个功能、每个介面设计细节、每个商品推荐逻辑，不是经过A/B测试验证，就是正在A/B测试。
酷澎执行A/B测试的模式是观察新做法相较既有做法的对使用者体验的影响，不会一次测试两种新功能。执行测试时，工程师会撰写App改动程式码及指标监测程式码，前者会部署到正式版App，在实际商业情境中观察顾客体验指标，后者则会撷取实验相关指标，来监控实验环境及顾客反应。
每天，酷澎App上执行超过1,000个A/B测试，需要处理30亿个相关事件。为了确保这些测试能妥善进行，且不会影响到App稳定度、顾客体验或其他测试，酷澎打造了实验平台，中心化检查实验前程式码、管理实验设定、监控实验指标、通报实验异常、自动终止不良实验，并根据各式指标汇整出实验结果报告。
用Lambda架构兼顾实验结果报告的时效性及准确性
实验平台中，最核心的系统是A/B测试系统，负责从顾客互动事件等指标来计算出实验结果报告。此系统采用了Spark平台来实现Lambda架构，分为快速处理层（Speed layer）和批次处理层（Batch layer）来各自计算实验结果。前者著重于快速产出结果，后者则强调高精确度。这两个处理层的计算结果，会再整合为最终实验结果，存入资料库纪录。
快速处理层的实验报告计算逻辑是，只会计算上次计算结果到当次计算期间的数据，每隔15分钟更新一次实验报告。这个做法的好处是，能让内部使用者快速窥见实验情况。不过，这种做法可能会因为数据延迟性等问题，导致计算结果并非百分之百准确，且偏差幅度会不断累积，最终使实验结果失真。
而另一个批次处理层，则是每次都会重新撷取实验开始至计算当下的原始数据，从头开始计算整体实验报告。也就是说，就算过往报告因为数据错误而产生偏差，只要后来数据有校正，便不会影响新报告。这种处理模式较费时，每1.5小时才会更新一次实验结果报告，不过结果更加精确。
为了同时计算上千个A/B测试的实验报告，这些运算过程套用了Akka框架来进行分散式运算。此框架下，Spark的运算资源能更有效分配给不同并行任务，且单一运ㄔ算节点当机时，节点会自动重启，不会连带影响到其他实验。
酷澎A/B测试系统采取Lambda架构，分为会用完整实验数据计算结果的批次处理层，以及一定时间就会根据当下可用数据计算实验结果的快速处理层。这样的设计，可以确保实验结果精确度，也支援高时效性分析。图片来源／酷澎
设计程式码自动化检查机制，避免A/B测试造成不可逆系统错误
酷澎App高达8成的技术事故源自于A/B测试。这是因为，一口气在不同作业系统、不同App版本、不同地区执行成千上百个实验时，工程团队难以巨细靡遗检查每一行程式码。
发生事故时，酷澎会撤销A/B测试的B程式逻辑（新做法），将所有使用者导回稳定的A程式逻辑（预设做法）。然而，很多时候，实验程式码没有确实分割A/B程式逻辑，导致撤销B逻辑会连带使A逻辑也发生异常，事故处理变得更加复杂。
为了减少这种情况，酷澎打造了一个程式码检查机制，自动辨别可能造成A逻辑更动的程式码，并通报开发人员。
这个机制分为4个步骤。第一步，当实验者提交A/B测试用的App程式码，系统会于Git层级侦测测试程式码相对于原始程式码的异动，分为新增（Addition）、删除（Deletion）、更动（Modification）3类。
第二步，系统会分别将原始App程式码及测试程式码转化为抽象语法树（AST，Abstract Syntax Tree），以树状图呈现出程式码架构，来两两比较差异。前一步侦测到的异动程式码，会进一步分类为新增、删除、更动及移动（Movement）4种模式，以供后续检查。
第三步，前述4种异动程式码，会根据各自检查规则来分析语法和执行顺序，以判断是否会影响A逻辑。举例来说，如果新增了一行宣告式程式码，但还没有于他处被呼叫，就会判断为无影响风险；若新增了一行在A跟B逻辑都有可能执行的表达式程式码，则会判断为有影响风险。
第四步，系统会标注出有影响A逻辑风险的程式码，再发出警告，要求重新调整程式码。若程式码影响幅度很大，连风险程式码的上层程式码都会连带标注。
酷澎强调，他们使用的判断规则不一定适用于所有部署环境和系统架构，更不是万灵丹。不过，启用此检查系统后，错误程式码行数减少了27%，B逻辑实验连带影响A逻辑的情况也减少了30%。
酷澎会自动化检查A/B测试程式码是否有将A/B逻辑完善切割，以避免事故发生时难以复原回既有逻辑。图为新增程式码的检查规则，若程式码被判断为有影响A逻辑风险，就会通报工程师修改程式码。图片来源／酷澎
打造规则式自动监测系统，大幅简化实验监测流程
执行A/B测试时，数据工程师和数据科学家必须监测许多数据指标，这包括系统面的延迟、错误率、测试族群分配、流量，以及使用者互动面的转换率、点击率、停留时间等。
指标监测机制的设计和部署都相当复杂，因为追踪指标数量多、许多指标会相互影响、程式码需要和不同系统沟通，而且不同指标还需要不同判别方法及应对动作，例如某些指标达标会要求直接终止实验，另一些指标则需要通知实验者来调整实验方法。
以前，酷澎工程师部署监测机制需要花上2周，当实验方法中途有调整，监测程式码还必须随之调整。为了降低监测实验指标的时间和IT人力成本，酷澎设计了一个规则式监测系统，统一管理指标数据查询和执行终止实验等后续动作。也就是说，工程师部署监测机制时，只需对这一个系统设定查询指令和不同指标触发的动作，大幅简化过往作业。
这个监测系统的运作模式是，与A/B实验指标相关的原始数据会存放于MySQL，这些原始数据会抛转到一个时间序列资料库。系统每分钟自动对时间序列资料库执行一次查询指令，当指标达到一定门槛，则会执行工程师当初设定的动作，例如自动终止实验，或发送警报给实验负责人。
转换率下滑时快速通报，10分内自动中断不利消费者体验的A/B测试
A/B测试对象是酷澎消费者，若测试中功能明显造成消费者体验下滑，会有降低获利，甚至流失消费者的潜在风险。
为了减少这些损失，酷澎做了通报系统，在消费者转换率明显下滑时通知实验负责人。不过，此系统采取批次运算模式，最快反应时间是4小时，止损能力有限。后来，他们打造了新通报系统，利用Spark Streaming每隔2分钟分析一次串流资料，大幅增加数据即时性。
酷澎判断新功能导致消费者体验明显下滑的指标是新功能与消费者转换率关联性。若系统连续5次计算都判断新功能拉低了转换率，便会自动终止A/B测试，并通报实验负责人。也就是说，从消费者体验明显下滑到测试终止，反应时间只需10分钟，是先前系统反应速度24倍。
A/B测试可能会导致使用者体验下滑。酷澎会追踪测试功能的消费者转换率，若明显降低，最快10分钟就能自动终止实验。以此图为例，新功能转换率低了20%，若无法快速终止实验，会损失大量潜在营收。图片来源／酷澎
用ZooKeeper管理A/B测试设定数据，以维持大量实验稳定性
酷澎他们使用ZooKeeper来统一管理储存A/B测试所需的设定数据，例如测试OS、App版本、A/B测试受众设定等。当测试方法有调整，ZooKeeper会快速同步设定到10,000个负责处理A/B测试设定的分散式运算节点，以避免不同节点设定暂时产生落差，进而影响实验品质。
ZooKeeper运算节点分为调度运算工作的领导者节点（Leader node），以及负责执行这些工作的追随者节点（Follower node）。这些节点会持续进行领导者节点选举（Leader election），依照节点可用运算资源等状态来认定领导者节点。
不过，这些节点的资源常会随著使用者连线情况浮动，造成领导者选举不稳定，大幅影响分散式运算效率。为了解决此痛点，酷澎加入了一种新节点，名为观察者节点（Oberserver node）到运算环境，专门处理使用者连线相关任务，且不参与领导者选举。为了进一步降低使用者连线延迟，酷澎还打造了SDK，利用虚拟资料中心（VDC）设定来寻找离系统最近的观察者节点。有了这些做法，领导者和追随者节点便能稳定执行领导者选举，进而维持分散式运算效率。
ZooKeeper处理数据量极大，每当更新后重启，ZooKeeper于开机阶段会一次传送超过100GB的设定数据。为了确保节点间频宽，酷澎选择将ZooKeeper JVM部署于较贵的频宽保证执行个体上。
酷澎表示，实验平台上的许多机制都是为了规模化而设计。有高速、稳定、精确、标准化进行大量A/B测试的能力，不仅使酷澎于韩国拓展业务规模及多样性时能持续用数据来驱动决策，甚至进军多国市场时，他们都有意用同一套实验平台来管理全球业务所需的A/B测试。