开发者学堂课程【大数据SRE体系能力建设 ：大数据 SRE 体系能力建设（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1203/detail/18170
大数据 SRE 体系能力建设
内容介绍
一、 服务团队介绍
二、 大数据 SRE 体系能力建设
三、 头部金融客户建设案例
一、服务团队介绍
首先介绍金融 TAM 大数据专家团队。金融 TAM 大数据专家团队是通过金融行业的大数据专家的服务解决方案，帮助数据中台客户解决大数据的告警对接、流量管理、性能调优、业务的稳定性治理、环境账号权限体系管理、数据迁移、运维巡警、变更管控、性能测试、故障应急、容灾演练、护航保障等大数据 SRE 体系的建设需求。目前已为十多家的金融客户提供专业的大数据 SRE 体系建设的服务，支持客户重点打造具备生产支撑、应用支持、平台治理、业务护航保 障以及技术指导能力的一大数据专家团队。
服务的对象主要是客户侧的大数据的专家团队和大数据的运营团队。服务内容涵盖监控告警、容量管理、新闻测试等等， 涵盖了平台业务的各方面的内容。
下面是整体解决方案的一些使用场景和亮点。大数据专家服务的使用场景主要针对于大数据的业务告警，对接大数据的容量管理，数据 SRE 体系的能力建设以及运维赋能、技术指导以及方案咨询，主要从 6 个使用场景来进行开展。
首先在此方案中共有三大亮点。第一大亮点是告警对接方案，当前在专用云的大数据的场景里面，客户离线的数据，比如 data word 、 odps 离线场景和基于 Bilink、 data hub 的实时利用场景，还有基于 hello Grace 实时场景，他其监控员都是分离的，目前没有统一的告警接口，对外提供服务。客户希望能够将阿里大数据云内的告警和客户自有的技能体系的平台进行对接，来实现云内的告警，能够及时有效的触达到客户自有的金融运营管控平台，通过统一的监控的采集、处理加工，将云内的大数据告警，包括离线任务，实时任务，水位及稳定性的告警，能够及时有效的发送给金融客户自有的运维体系。第二个亮点在于可以帮助金融客户来实现在大数据去中台场景里面的业务和实例级别的容量的分析和管理来达到开箱即用。如此是解决什么问题？就是为了解决目前在数据动态场景里面，对于离线计算各场景里面做项目级别的容量的 分析管理划分。目前的看法是没有一个足够的透视能力的。通过供应建设，让客户能够看清楚业务或实例项目级别的分配和使用的情况。比如在做一些资源合并时，将一些分配资源量比较高，但是使用率比较低的项目的资源划分给其他更重要的项目。或者也可以为一些比较重要的业务 dedicated 独占的项目的 quota ，或者调度资源组。 第三个亮点，团队可以通过整体 SRE 体系能力建设，比如稳定性治理、性能调优、账号权限的体系的划分和管理、数据的迁移、护航保障、应急演练等等。帮助客户能够具备足够的能力来管理好大数据平台，来解决目前很多客户反馈的大数据的业务支撑难度比较大的问题。让客户具备生产支撑、应用支持、互联网保障、技术指导以及平台治 理等大数据专家能力。在对外输出的场景里面，主要针对于大型的银行，大型保险，还有证券基金公司。对于大型的保险公司，其主要业产在于银行的保险公司的代理人，包括智能营销，精算会计，资本分摊和风控。对于银行来讲，更多的可能在于智能的贷款、反欺诈，还有特征的工程、征信等。大数据业务场景对于证券基金公司，其实其业务场景更针对于客户，洞察客户的一些资产管理，智能投资风控。所以每一个不同的金融客户都具备不一样的体系，所使用的大数据的场景也不一样，可以做针对化的输出。目前在头部的保险和银行客户，比如太平洋保险，广东农信、四川农信、贵阳银行等银行机构， 包括瑞士再保险，诺亚财富都有案例的输出。
二、 大数据 SRE 体系能力建设
大数据 SRE 体系能力建设，为了确保大数据业务连续性提升目标。可以通过三方面内容进行建设。第一方面，可以通过一些规范与机制的构建，比如变更的规范，变更的管理。什么叫变更的管理？变更，实际要满足变更的三要素，比如可观测，可验收，还有可回滚。如果变更不能满足三个要素，变更不合理的，是需要进行驳回。第二方面需要发布的规范，需要制定业务发布里涉及到的整体代码的规范，整个发布流程的规范，配置的规范。另外还有账号权限，比如在不同的环境里面，给予对应的账号适当的权限管理。包含故障再问题复盘， 运营透视，比如故障应急演练，日常的变更，日常预防和监控，巡检或者监控等等，都是正常的规范和机制的，此构建更偏流程化的体系的建设。另外还可以通过一些专题的治理，比如可以通过金融告警的治理，把舆论告警托给银行方或金融客户，通过容量管理增加一个平台的容量管理透视能力。另外可以通过环境、账号权限的规划，把大数据中台的数据的安全性做得更好，包括视频矩阵更清晰。开展性能测试，来确保整体的实时链路里面业务的训练，是可以满足业务方需求的。同时可以开展高可用的演练，来确保平台的高可用能力。第三方面需要有一个自动化平台支撑，比如监控平台，管控里面做日常的巡检、 变更发布、 CMDB ，通过 CMDB 需要维护平台里面的机器服务的业务归属的元素信息。同时需要构建一个数据化的运营，把存储的数据、调度数据、任务数据和巨量数据做统一的视图，通过一套数仓提供数据运营的能力支撑团队做一个规划，也会支撑业务方做合理的容量管理性能观测、稳定性分析等等。最后是演练工具，比如做高可用演练，容灾演练，应急演练，还有事件，事件主要针对于日常的发生的一些线上的故障的复盘，风险事件的跟进等等。由此通过三大内容，可以 cover 云内的 data boss 数据开发平台、 max computer 、离线数仓、 datahub 消息总线产品，还有 hologres查询的产品等等主流产品都可以将其涵盖在内。
目前是能力建设内容，可以通过图区分出。整个能力的构建，通过两个维度，一个是绿色的流程的体系，一个偏流程的能力建设，第二个是偏工具化的，一个建设偏黄色标志，同时在场景触达实际要关注运维的，哪些是运维关注的，哪些是业务方关注的。比如数据化运营，可以通过构建一个涵盖的任务的存储的计算调度的信息的数仓， blind 一个数据化运营的平台，做一个业务大屏， 或者做一些数据化分析，能够识别整个平台的任务和存储计算整体人员情况。对于应用团队、业务团队，是希望能够区别出来哪些是异常的任务，比如异常的 SQL ，可以识别大量的异常的资源开销和 CEO 开销的任务，或者是否存在大量的长尾的任务。对于运营团队，希望通过平台能分析自己平台的健康度和经销分，识别整个平台的调度是否合理的，存储是否存在风险，存储物理数据的空间和元数据空间是否存在风险， 另外选运营流程题建设，涉及到变更管控和开发的规范，然后是验证，包括变更的三要素，同时应急预案需要有前期的事先的预案，事中的演练和事后的复盘的能力。因为团队更多的怎么能够掌握应急止血的能力。对于业务方，希望流程在线上完成，比如冒烟验证，或者性能测试等等。包括代码发布的 csd ，因为金融客户的一些数据中台的代码开发是交给 SIV 进行开发的。如何管控 SIV 的代码的质量，发布流程后，客户自有的平台进行统一的管理，需要有一套机制流程进行合理的集成。包括一些工具化建设才能够把整个的能力建设起来。
在 sre 三阶段建设过程中，其实 sre 建设能力不是必须只有在运维阶段才会进行开展。首先整个业务发布分成，上线前，开发和测阶段， 上线后的生产运营阶段，尤其涉到开发规范的定义和服务的降级， 包括依赖的治理。只有定义，才能够提前把基线和核心任务梳理出来， 当万一发生问题的时候，可以做合理的降级止血，来区分哪些业务需要得到重保。第二是测试，包含功能测试，性能测试， SIT 测试， UAT 测试。在大数据场景里， 可能用 ABtesting ，还有基于终端的业务 指标验证。对于生产方，当业务发布了，就要进行一些生产发布的运行的观测，还有一些运维，包括一些变更回滚的动作，整个流程里面涉及到开发 测试，发布，应急等流程。所以建议在整个 SRE 提供中，需要把发布的规范，测试的规范，开发规范，应急的规范，提前梳理好，避免当市场出现问题的时候，被动的应对。比如提前将巡检监控指标进行梳理，就可以对于以后运行进行观测，同时对于异常的告警进行处理， 降噪或者进行收敛。
