17Live集团旗下服务的用户超过5千万人，遍及全球，如何持续地提供稳定的直播服务，靠的是背后一支强而有力的团队，随时洞察系统状况，发生异时常，第一时间查找问题，并即时回应各单位，快速采取应变措施，他们就是SRE团队。
2017年时，17Live关注到Google大力推行的SRE运维方法，切中他们想强化服务可靠度的目标，希望运维人员可以跳脱运维工作上的传统框架，不再只是负责管理机器，而是更密切地与不同单位的人员接触，提供他们需要的基础架构支持，因而决定将DevOps团队转型为SRE团队。
过去曾有运维工作经验的17Live集团工程总监林毅民，现负责率领这个SRE团队。他指出，传统运维团队多是负责一些例行工作，例如，主机监控。他指出，这样的工作内容让运维团队像是一个后勤单位，不容易彰显价值。但是，“导入SRE做法，可让运维工作变得有价值、有意义，不可被取代。”林毅民强调。
尤其他想要以研发角度开发内部软件，来取代高度重复的例行运维工作项目。像是监控工作，SRE工程师可以创建自动化监控机制，只有当流量超过设置门槛，运维人员收到警急警报后，再展开行动，不需像过去得时时待在机房监控状况。
不仅改变运维工作的执行方式，林毅民更要塑造SRE团队成为，“17Live内部的信心来源、可信任的对象”，来支持开发团队在每个上班日发布部署服务新版本。
他解释，SRE团队要带给工程团队的，不单是做事方法、做事原则，而是，一份可靠度、信任感，让开发团队感受到，有SRE在，他们可以放心地交付功能、服务。
5大角色组成SRE团队
17Live所打造的SRE团队是多功能团队，可以分为5个组别，第一个是数据库团队，负责管理各类数据库，包含了RDB、NoSQL、Redis等，负责创建机制来监控数据库的各种指标，并与开发工程师讨论如何优化查询；第二组是基础架构团队，负责支持两种云计算环境：GCP和AWS，以及配置公有云环境里的容器，并打造完整的监控系统，来确保集群的稳定性；另外，还有自动化团队，利用软件开发概念来改善基础架构的开发工作，像是自制各种Slackbot。
再来，还有一组安全团队，负责从系统、应用程序和容器不同面向，强化信息安全，确保有效阻挡潜在风险或外来攻击，如DDoS、SQL Injection等，还有培养全体企业人员正确的安全观念，无论工程人员或非工程人员，都须落实安全防护作为；最后一组人马是技术服务团队，相当于一般企业服务内部员工的IT部门，负责提供全球17Live人员的信息服务，目标提升全体人员的个人生产力，及提高内部沟通效率，并协助各部门盘点系统采购的需求。
这种多任务型的技术服务团队出现在SRE编制中，相当特别，林毅民解释，他们扮演的是各部门的IT咨询顾问，要赋给内部人员使用的信息产品信赖感，他提到，以往IT都是用传统、简单的方式驱动内部信息化建设，他以监控工具使用状况的工作为例，IT人员多仅确认各单位人员有没有使用生产力工具。
在17Live，SRE团队要利用自身运维经验，向内部各单位不管是业务、人资，还是财务部门，提供更敏捷的工作方法，来提高工作生产力，进而营造SRE是一个可信赖的单位，除了确保服务可靠性，还可增进人员的工作效率。
从4阶层制定SLI，监控服务稳定性
随着17Live决策团队开始采用目标与关键结果（Objectives and Key Results，OKR）的管理方法，制定全公司的共同目标，而各业务单位也需要测量指标作为基准，来衡量不同时点的服务状态，与预期目标上的差距。
因此，SRE团队在去年制定了服务稳定性指标（Service Level Indicator，SLI），从4个层级：集群、系统、应用程序和源码逻辑，来监控服务的稳定性。除了侦测CPU、内存或磁盘容量等常见资源的指标外，还会侦测网络I/O、磁盘I/O等。另外，目前在监控系统运行上，17Live使用的是监控服务Datadog，也通过VividCortex更细微地监控MySQL指标。
林毅民表示，任何细节对17Live来说，都至关重要，SRE会与开发人员一同构建这些监控指标。这些SLI指标除了是各单位衡量OKR的参考标准，更是SRE团队在服务发生异时常，找出影响服务稳定性起因的主要依据。
以应用程序自身发生异常的状况为例，SRE团队有时无法从系统上直接看到异常的流量情况，必须通过监控机制的指标才能判断，究竟是服务的哪个层级发生问题。
甚至，过去17Live曾遇到云计算供应商服务出现问题，但警报系统没有发现流量下滑的异常，直到用户抱怨无法登录，他们才意识到问题。林毅民提到，后来，一旦发现了异常警报机制无法掌握的情况，SRE团队就会尽快增加更多监控指标和警急通报，希望能在用户反馈前即发现问题。
除了针对系统运行状态制定监控指标，17Live SRE团队还创建了另一套，从运营端角度来观测服务稳定性的灯号仪表板。该机制罗列服务会发生的各错误，再依错误的严重程度分级为P0、P1、P2、P3，而每一个分级都有自己的加权分数。
这个灯号监控机制背后有一支程序，每天会计算，当日往前推30天内，服务发生了多少次的错误，再从100分往下扣除所有错误加权分数的总和，来代表整体服务状态的总分数。这个分数不只用来观察服务状态，也会影响17Live工程团队的开发优先级。
这个总分数若大于80分，仪表板会显示绿灯，代表17Live现在可以开发一些风险比较高的新功能；黄灯是介于60到80分，代表SRE团队以及后端工程师必须投入在维持系统稳定性；红灯则是低于60分，代表工程团队全体成员都必须花更多时间优化稳定性，并且，调整部分工作调度，尽可能避免高风险的新功能上线。
待命机制每15分钟更新一次当前问题处理状况
有了完善的SLI，一旦SRE团队监控指标的数值，超过设置的水位，就会触发待命（On-call）机制，通知当日值班待命的SRE人员，或是后端工程师。林毅民表示，后端工程师也须待命轮班，来了解SRE如何排除问题。
有时待命机制发送了错误警报，为了避免“狼来了效应”发生，每一次都会找来后端工程师比对，确认和修正警报的正确性，他强调，每次警报触发都需待命人员，扎扎实实的排查问题。
为了有效启动待命机制，17Live SRE团队还集成了警报和待命管理工具Opsgenie，以拨打电话或是发送短信的方式，自动通知轮值的待命人员。
待命者收到警报后，5分钟内必须立即上线，开始调查当前问题发生的状况，排除问题。若判断疑似是当日服务发布的新版本造成问题，为了快速修复，值班人员甚至有权限直接退版，还原到前一版功能，不需先向主管报备。
如果不是服务上新版的问题时，值班人员需监控其他资源的指标，例如数据库、基础设施等，通知指定相关人员上线排解。一旦，经10分钟仍然无法解决问题，17Live要求，必须即刻通报SRE主管及工程团队技术副总，向上拉高事故处理的层级。
接着，SRE主管会随即成立紧急应变小组，以15分钟为单位，持续向17Live全球人员更新问题的最新状况，让所有人员同步了解当前状态、处理状况，以及预期服务可回复的时间。
林毅民表示，每15分钟发布一次问题状况，可以让全体人员安心，了解当前处境，知道应如何安抚自身面对的用户，像是VIP观众、直播主等都需要了解状况。
等到问题都顺利排解后，SRE团队还需知会此问题的相关人员，来撰写检讨报告（Postmortem，又称验尸报告）。林毅民表示，这是取经自Google的SRE做法，应用到17Live整个工程团队上。
不过，17Live没有照单全收，而是将Google原始的检讨报告做法精简浓缩。撰写时主要聚焦4大要点，包含整起事件的时间轴，从故障何时发生，到修复过程各时间点做了哪些事情；再来是背景信息，说明问题的根本原因，故障造成了哪些状况；
还需要撰写改善事项（action item），需采取哪些动作来防范类似问题再次发生；最后一项是从这次经验中学习到的事（lesson we learned），未来若遇到相同情况应如何解决。
林毅民表示，撰写检讨报告可带来许多好处，让工程团队知道如何解决问题，以及改善，避免问题再次发生，甚至可以帮助提早预知问题，提前做相应的对策。
不过，他强调，故障发生当下，SRE团队不会马上花力气找根本原因，而是先降低故障几率，或是减轻影响范围。等到故障都排除之后，再回头查找根本原因，撰写检讨报告，而公告检讨报告后，还会召开检讨报告结案会议，来确保已确切执行各改善事项，并持续提升系统的稳定度。
17Live集团工程总监，同时也是SRE团队主管的林毅民表示，传统运维团队做的多是例行工作，无法彰显工作价值，导入SRE做法后，以软件工程角度来解决基础架构面临的问题，“可让运维工作变得有意义，不可取代。”（摄影／洪政伟）
SRE团队已经历4阶段挑战，首先，面对公有云环境转移工程
17Live SRE团队成立4年多来，已经历了4大阶段性的挑战。首先，随着业务规模持续扩大，开发需求越来越多样化，为了使用GKE来获得更好的Docker支持，让容器化开发环境更具弹性，集成每日处理资料量多达1TB的GCP资料分析工具，如BigQuery，17Live在2018年5月时，用3天时间，将服务从AWS迁移到GCP。
能够3天完成这项搬迁工程的背后推手正是SRE团队，这也是SRE团队头一次面对如此大型的搬迁工程，因此，团队早从前一年就开始着手准备，讨论如何做才能减少中断时间，降低两大用户：直播主和观众，在使用服务上面临的影响，足足耗时约半年才完成了缜密的搬迁工程计划。
SRE团队先在云计算测试环境中，借由不断测试不同的搬迁方式，来计算中断时间，也一步一步抽丝剥茧，寻找潜在的风险。
为了避免一次性搬迁后，单一服务在新环境中，被涌入的正式流量冲爆，导致整个服务器宕机，最后，决定分3天进行搬迁工程，依次搬迁MongDB、MySQL，还有最后一天迁移了应用程序和Redis。
确立搬迁方式后，SRE团队还进行了约10次的演练，模拟整体服务的搬迁过程，就是要确保所有流程顺利。最后，17Live不但顺利将服务搬家，且历时3天的搬迁工程，每天中断时间都介于5到10分钟。
借由这次的云计算迁移经验，SRE团队创建起执行大型搬迁、升级任务的能力，知道每个环节从事前规划、测试到执行，需要思考、准备哪些细节，再加上如何执行数次扎实的演练，才能最大的减少中断时间，以及排除最多的可预期状况。
除了通过自我不断演练来确保搬迁工程顺利，SRE团队还创建了与各业务单位沟通工程内容的能力。林毅民表示，工程团队过去因公司初创立组织规模较小，执行技术转换工程时，不需考虑太多面向，可以直接切换，然而，随着组织扩编，产品和用户数量大幅增加，执行任何工程需考量的风险和沟通对象也增加。
进一步看，SRE团队与各个业务单位事先宣布了工程技术转换的时间点，确认服务用量在该时间是不是最低，并沟通转换工程期间会发生哪些状况，还有说明回溯计划。林毅民解释，不断演练，还有沟通回溯计划，就是为了让内部有信心，让大家知道，若不小心发生问题，甚至是失败，还是可以回复。
挑战2：转换应用程序语言，减少重复性运维工作
相隔一个月，同年6月，为了落实SRE的另一项运维理念，也就是“减少做重复性工作项目”，17Live把所有应用程序从Node.js，统一改为后端常用语言Go语言。SRE团队与后端工程师一起前后花了一年的时间，转换程序语言，一边更换既有应用程序语言的同时，一边用Go语言写新功能。
转换期间，不同语言开发的新旧版API同时混杂，为了让新服务可以更顺畅在Go语言的环境上运行，SRE团队特别开发了一层类似API网关的监控工具，确保新版服务API能循着正确的程序语言途径来执行。林毅民解释，有时改变应用程序语言，不一定能提升应用程序性能，所以，必须监控。
挑战3：云计算服务故障超过10小时，促展开多云架构布局
搬迁服务至GCP后，17Live以GKE执行容器来负担各种线上服务，然而，强调高可用性的云计算服务，不会百分百正常运行，SRE团队需要随时监控系统状况，应对突发事件。
林毅民印象最深刻的一次，2019年11月万圣节隔天，GCP发生大规模故障长达12小时，导致17Live无法添加机器，来满足当日直播服务尖峰时段的使用需求，这是SRE团队成立以来遭遇的第三大挑战。
SRE团队虽在GCP发生故障之初，即发现问题，然而，此次事件却大大冲击17Live服务。因为，故障事发当下为午间时段，17Live系统正处于离峰状态，无法正常扩展容量，晚上就是高峰期，现有的系统资源肯定支撑不住流量。
再加上，17Live主要功能都集中在少数服务上，所以，一旦服务内部分功能耗尽了计算资源，例如CPU，也会连带影响到该服务的其他功能，造成全面性的灾难。
SRE团队虽很快采取多项应变措施，像是限制用户数、关闭次要功能，或是移除运算需求低的容器，挪出更多计算资源，来接手执行关键容器，林毅民坦言，但是仍旧缺乏可以积极、主动排除问题的方式，现在回想起来，他苦笑的说：“面对GCP故障，他们只能双手一摊，无尽的等待Google修复服务。”
这次灾难应变经验促使SRE团队意识到，如果只采用单一云服务环境，当云计算企业发生问题，他们能做的事其实不多。林毅民表示，那次的故障事件，让17Live正视只用单一云计算环境的风险，开始布局多云架构的策略。
于是，SRE团队重回AWS环境，创建灾难备援机制，来应对云计算服务的突发状况。现在，17Live只需要一个脚本程序，就能在20分钟内，构建好AWS EKS环境，30分钟内可以将大部分的服务完全重建。
挑战4：数据库达吞吐量逼近上限，切分数据库
由于用户及功能数量不断的增加，17Live数据库资料量和吞吐量也越来越大，逼着SRE团队在去年11月，面临拆分数据库的压力。林毅民表示，如今数据库用量为2018年的3倍，已经达到单一集群的吞吐能力上限，而且当单一集群发生问题，整个API服务会无法正常运行。
SRE团队规划了服务降级的解决方案，与后端工程师一同以功能面来切割数据库，将数据库一分为五，其中最大的难题是，如何有效以功能面切割数据库，因此，也请测试工程师加入，一起将功能切成不同种类的测试案例，来不断测试，确认功能是否达预期表现。
SRE须勇于分享、发问，从不同角度切入问题
林毅民强调，SRE人员必需要具有勇于分享、勇于发问的态度。
他表示，17Live SRE团队由不同背景的人员组成，有些人过去是销售工程师、机房运维人员或是数据库管理人员，每个人有不同的领域知识。因此，成员会用不同的思维切入问题，不管是从数据库、运维端或是用户的角度思考，所以，林毅民尤为注重勇于发问和勇于分享的态度，他表示，只要人员敢问，别人也分享给你，如此，就可以塑造正向分享、发问的循环。
对于想导入SRE工作方法的企业，林毅民建议，参考Google SRE做法，但，他强调，不应完全套用所有做法，因各企业不管是组织规模、协同方式、产品都与Google不同，因此，企业须将SRE做法转换为自己的东西。他点出SRE实例的唯一重点是，不能有怕事的态度，要勇于跟其他部门沟通，如果害怕踩到其他部门的界线，就无法成就任何事。