1、B B站平台工程站平台工程实践实践毛剑毛剑 bilibili bilibili个人简介个人简介毛剑，目前就职于 bilibili、负责基础架构部、质量保障中心、C端技术中心、游戏技术中台总经理，同时兼任技术委员会主席，近十多年的服务端研发经验，擅长高性能、高可用的服务端研发，熟悉 Go 等语言。在B站参与了从巨石架构到微服务的完整转型，在内部推进了 Go 语言，以及微服务的发展；之后负责过工程效率，对于分布式增量编译，以及 CICD 有比较丰富的经验；19年负责公司数据平台，把离线、实时、OLAP 平台底层能力拉到了一线互联网公司的水平，现在集群规模超过EB级别。目录目录 B站文化和团队（De

2、vops、EP、SRE）的发展DevopsDevops文化的发展文化的发展DevOps的技术发展旨在让开发者更专注于业专注于业务本身务本身，去实现需求，将操作降至最低。烟囱式，各自变更协调到单一的发布流程；原子能力，EP和SRE的团队转型1；平台工程；如果没有一个高度的工程纪律和来自管理层的认可，这一种精妙的平衡很容易退化成传统的“我们和他们”之间的竖井，从而导致团队间频繁的服务故障和不信任感加剧2。EPEP（工程效率）团队的发展（工程效率）团队的发展2018年，EP团队的重点工作主要在三方面：可靠性：全链路压测平台；效能：染色（多租户）环境管理、CI流水线；质量：移动端等专项测试基建；形成了

3、平台即服务平台即服务（PaaS），业务团队使用服务能力，提高工程师的自主性。Gitlab Flow-Agile FlowGitlab Flow-Agile FlowSRESRE（可用性工程师）团队的发展（可用性工程师）团队的发展2017及以前20021-至今 效率优先 需求响应、变更、标准化、报警治理、琐事优化 无稳定性工程 理解业务架构而非完成业务需求 积极推动读多活建设 建立Oncall制度 建设故障复盘文化 思考我们如何实践SRE 大型活动保障工程建立 混沌工程和故障演练探索实践 PaaS容量管理体系建设 稳定性工程初步完善 琐事优化释放人力转型 服务分级体系建设

4、SLO工程与平台建设 应急响应制度建设 故障复盘平台和故障管理制度建设 积极推动读多活业务覆盖 SRE BP制度，业务伙伴 专注稳定性建设和降本增效 多活、服务分级、SLO、容量管理等体系再优化建设 全员转型SRE，转型开发，更高要求，更大挑战引入SRE文化SRE稳定性工程初步完善没有SRE，只有运维SRE探索与落地SRE再转型CI/CD CI/CD 全景图全景图我们是否会因为组织结构而导致一个更好的设计无法实现？“713713事故事故”背后的组织升级：基础架构部（背后的组织升级：基础架构部（InfInf）推动工业化推动工业化SRE：BP制、强制轮岗、平台体系建设（数据/运营）；AI&Bigd

5、ata：紧贴数仓服务业务，最大化复用SRE平台体系，推广搜支持；中间件：专注、深入引擎，为组件质量、稳定性、效率负责，SRE团队配合平台化；基础平台：为应用/中间件提供资源，全容器化；统一技术规划，为稳定性、效率、成本负责。推动了我们团队拓扑2，把产品团队独立，构建抽象层，降低认知负荷。目录目录 形成平台工程理念，及实践云原生生态的云原生生态的认知负荷认知负荷：业务团队关键任务业务团队关键任务应用需要众多云原生技术解决问题，却不幸引入认知负荷认知负荷77问题，苦“全栈”久已56。导致缺乏经验的开发人员向高级后端工程师寻求帮助，或者PaaS Oncall，经验变成了“部落知识”3。通过构建内部开

6、发平台来减少开发人员的认知负荷、艰苦的重复性手工工作，从而改善开发体验；平台不会强制使用特定的工具集或方法它是为了让开发人员可以更容易地构建和交付软件，同时又不用抽象出底层核心服务中实用的差异化功能；平台工程团队将平台视为产品（供开发人员使用），并设计出可以自助使用的平台；平台工程是什么？平台工程是什么？设计和构建工具链及工作流的学科，为云原生时代的软件工程组织提供自助服务能力。平台工程师提供一个通常称为“内部开发平台”（IDP）的集成化产品，涵盖应用程序整个生命周期的操作需求。统一门户：提供了一个具有服务目录功能的UI和OpenAPI；统一元数据：服务树、CMDB等各类PaaS元数据；统一工

7、作流：围绕应用的生命周期平台化；以产品思维产品思维为驱动，将开发者视为平台客户。围绕：“开发人员愉悦（DevEx）”运营和数据驱动思路迭代。团队拓扑（团队拓扑（Team TopologiesTeam Topologies）：组织组织平台平台团队团队平台团队：提供一个令人信服的内部平台，提高业务导向团队的交付速度。平台团队与其他所有团队都是平行的，旨在确保从编码到生产的自助工作流的流畅运转13。协作协作，服务服务，促进促进。平台工程运营实践：平台工程运营实践：简化开发简化开发、弱化弱化“全栈全栈“、知识转移知识转移在推进平台工程，人们最常犯的两个错误是：一、不关注团队之间的互动；二、没有严肃地对

8、平台产品负责人这样的角色进行投资8；三、组织结构升级。构建全新的接口，将底层的公有云服务完全抽象；简单地向所有用户公开所有的公有云服务，并简单地将身份管理和成本控制（Finops）的所有权交给“平台团队”；团队成员（包括产研、SRE）既有具备基基础设施运营经验础设施运营经验的人，也有可以代表平台用户的人，而产品经理负责确定功能优先级及平衡竞争性需求，并致力于确保你可以从平台用户那里获得可靠的反馈。工具之间的互联，通过开放的API形成一个网状连接9平台工程运营实践：平台工程运营实践：关注研发体感关注研发体感平台+技术驱动，规避影子设计。运营需要做到反馈循环，重视用户体验（UX、DevEx）：预期

9、管理：需求要考虑，但并不照单全收；KO+分享运营（文档/视频）+技术分享；反馈循环：问卷、核心KA例会、新人Landing；白皮书：使用场景、路线图、迁移手册；实时满足：Low Fruit 快速建立口碑；服务：API、易用、测试、部署、调试、文档；心怀感激面对他人的批评，给予足够的“认同提示”10。4A4A原则原则：Aim to assist、Actionable、Appreciate、Accept or discard。目录目录 SRE参与平台工程SRESRE：优秀的云原生架构师：优秀的云原生架构师12SRE 的工作包含两方面：对于基础设施的SRE支持来说，需要对这些设施的研发进行紧密的协作

10、；另外还包含日常的常规的SRE的工作（例如 Onall）。SRE 对线上安全生产直接负责（包含稳定性、性能等）。上述两个事实决定了SRE的沟通和协作是日常工作两个重要维度，SRE的负责人需要对这两块进行绩效考核，同时要相应的培训，特别需要注意认知偏差的出现。单兵作战通常都会失败，高价值的事情通常需要多人协作。SRE团队X熟悉Y产品（PaaS，例如Caster），专业化大幅度提供技术熟练度，但同时专业化会导致SRE局部化，忽视大局，因此轮岗在团队成员进行，以及Leader必须有更全貌的视角。这也是要求SRE成为云厂商（内部bili cloud）的SA（售前架构师，或者叫云原生架构师）。SRE大的

11、分工上分为：技术负责人（TL，专注在SRE平台建设，技术方向等）、SRE经理（SRM，专注在稳定性、效率等工作，也有开发任务，直面业务的人SRE BP，因为涉及大量沟通和协作，需要比较强的对内、对外的团队管理能力）、项目经理（PM，负责 Oncall 组织、Casestudy 组织、项目推进等）；SRESRE：优秀的云原生架构师：优秀的云原生架构师最佳的设计和最佳的实现往往诞生于生产环境运维与产品研发在相互尊重的氛围中进行的自由讨论（研发和SRE的视角决定，必须相互补位）。那么SRE必须承诺：一个专门负责可靠性（SLO），今天还覆盖成本（Finops）、效率（PaaS）的组织，拥有和产品开发团

12、队相同的技能，以量化的方式不断改善。这个事实决定了SRE，必须全面参与到Devops的工作，每个人包括Leader必须熟练掌握研发技能，这个也会是考核标准，相应的培训也要加速。须熟悉每个PaaS产品，成为专家、推广者，甚至是设计评审，安全生产评估等工作。SRESRE：优秀的云原生架构师：优秀的云原生架构师SRESRE基础基础 什么是SRE、SRE的职责团队管理和工作模式团队管理和工作模式 SRE团队转型、SRE参与模型、协作沟通 SRE琐事优化、中断管理拥抱工程、拥抱开发拥抱工程、拥抱开发 重视工程、运维自动化 50%人力参与开发SLOSLO工程工程 SLI度量、SLO工程、报警、运营SRES

13、RE日常日常OncallOncall 监控报警、变更、配置管理、消除琐事、简单化高可用高可用 关注系统高可用能力和架构设计故障生命周期管理故障生命周期管理 故障应急、故障响应、复盘和故障跟进日志监控TraceSLI度量SLO报警SLO运营监控报警发布工程配置管理工单处理消除琐事自动化系统高可用容量高可用变更高可用负载均衡降级、熔断超时治理分布式（去单点）性能优化多活容灾混沌工程故障演练弹性伸缩全链路压测在离线混布活动保障故障响应与协同故障排查与止损故障复盘与总结优化改进与跟踪发布工程配置管理流程审批平台风控SRE组织转型团队过载管理SRE参与协作演进拥抱工程拥抱开发目录目录 总结和思考总结和思

14、考总结和思考 团队优先：关注团队之间的互动，设计组织结构；平台团队：打造服务性的团队、优秀的体验、清晰的设计、良好的API和文档、利他的服务精神；Leader：全局最优的思路；围绕开发者体验（应用）的Allinone平台；Finops：货币化平台服务，驱动治理，挂靠经营单元；展望未来展望未来Prompt Engineering：基于意图识别（提示词）的平台；ReferencesReferences1 运维的未来是平台工程2 高效能团队模式3 平台工程应知应会4 超大型研发团队平台工程探索与实践5“扯淡的DevOps，我们开发者根本不想做运维！”6 DevOps黄了，平台工程火了？非也！7 平台

15、工程中认知负荷的挑战8 DevOps 缺少定义，平台工程需要指导性路线图9 高效研发:硅谷研发效能方法与实践10 Netflix文化手册：不拘一格11 蚂蚁规模化平台工程实践一年多，我们学到了什么？12 Google SRE:Google 运维解密ReferencesReferences13 平台工程/Platform Engineering是什么东东14 平台工程不适合中国企业？这个观点值得反驳！15 超越DevOps的平台工程：云计算背景下的平台战略和实施16 提升字节规模化效能的平台化思路字节跳动平台工程实践哔哩哔哩技术哔哩哔哩技术了解更多技术实践案例了解更多技术实践案例麦思博(msup)有限公司是一家面向技术型企业的培训咨询机构，携手2000余位中外客座导师，服务于技术团队的能力提升、软件工程效能和产品创新迭代，超过3000余家企业续约学习，是科技领域占有率第1的客座导师品牌，msup以整合全球领先经验实践为己任，为中国产业快速发展提供智库。高可用架构主要关注互联网架构及高可用、可扩展及高性能领域的知识传播。订阅用户覆盖主流互联网及软件领域系统架构技术从业人员。高可用架构系列社群是一个社区组织，其精神是“分享+交流”，提倡社区的人人参与，同时从社区获得高质量的内容。