个人总结之作业帮

导读

在作业帮工作7年了(2019-2026)，职业生涯的一半多。趁年底总结，把历年工作摘要放到一起，还不错、未虚度。顺手整理了第一个10年的技术历程，心安、无憾。

成长节点

• 19H2
  • 横向思维：延续滴滴的运维方法论，主稳定性、代工模式、服务者心态+成事的态度，从19H2持续到21H1。横向思维，有广度有格局(低阶格局)、但过于散焦，专业根基浅、价值难长久 —— 技术专业首先由纵向构成
• 21H2
  • 运维转型：横向思维后期、系统思维前夜，提出运维服务模型OPaS、并逐步完善成体系。21年SRE放弃研发保姆的定位，专注于平台工程、运维服务化(IDP)；23年SYS放弃资源管家的定位，专注于分级云管、资源服务化(ICSP)；24年补全横向解构大法，解构横向Toils、组合纵向专业，OPaS体系建设完成
• 22H2
  • 系统思维：接纳&践行自上而下的领域驱动、规划驱动、正向工程原则，以体系、架构为代表的系统思维，取代工具、组件、运营、产品视角，成为新的思维主体。22年集中产出FinOps、CM、CDN多云等优雅闭环，之后有更多更大型的体系落地
• 23H1
  • 业务建模：业务预单，从FinOps孵化、后迁移至资源和应用，抽象出资源中心、业务中心；23H1进一步价值觉醒，修正OP分工、不做架构之余。业务建模、价值觉醒，是体系思维在专业分工上的具象化应用
• 24H1
  • 认知体系：得到APP输入丰富的知识、视野、智慧，结合系统思维，抽象出个人的第二大脑、成长模型、创新方法论，认知格局飙升1-2档。从24H2开始，得到取代工作、成为主要的成长驱动
• 24H2
  • 数据基建：提出DIaC，从FinOps孵化出OLAP技术栈，之后广泛应用到资源观测、业务洞察
  • 精益运营：提出ODD，去技能化、运营驱动开发，尝试用低阶人才、维持复杂系统；23H2开始孵化，25H1基本成熟
• 25H2
  • 管理体系：21H1输入三明治模型、管理基本功两大理论，之后3年实践探索，产出了目标、审阅、分工、轮流、例外、去技能化、工程质量等多层解法；23H2整理工程质量体系；24H1管理觉醒，摆脱自省式PUA，修正温情主义、汰换落后人员；25H2提出组织工程，运用工程思维、建设组织架构，高内聚低耦合、消灭人人协作，管理体系正式成型
• 26H1
  • 基建AGI：一线实践、理论建设螺旋式演进，宏大建制、体系思维等高阶能力应用到AI革命浪潮

工作总结-年度汇总

25

• 方向规划：OPaS，发展出横向解构，终结传统运维模式
  • 横向解构：技术专业由纵向构成，要横向解构、由横转纵 => 为终结传统运维模式、提供了根本解法
• 团队管理：管理经验些许完善，如领域切割、组织工程，尝试消除人人协作的前提、而不是被动适应
• 技术成长：体系构建的方法论
• 体系建设
  • 25H1 管理体系，从20年输入管理理论开始，5年内探索除了分工、例外、目标、审阅、去技能化、工程质量，25H2升级为组织工程
  • 25H2 基建AGI，一线实践、理论建设的螺旋式演进，领域、架构、宏大建制等高阶能力终于成熟

24

• 方向规划：多云管理走向精细，包括CDN多云、OS黑产、云服务独立成项等
  • ODD，去技能化、运营驱动开发，用低阶人才、维持复杂系统
• 团队管理：在实践中优化框架，包括分工、例外、项目、治理等
• 技术成长：得到取代工作，成为最大的成长来源，反向促进了方向(如去技能化)、团队建设(如管理觉醒)
• 体系建设
  • 24H1 知识输入，得到取代工作、成为最大的成长来源，抽象出个人成长模型，之后1年持续反补工作
  • 24H1 管理觉醒，摆脱自省式PUA，安心淘汰落后人员、营造先进环境，不再为低阶的人和事兜底
  • 24H2 数据基建，提出DIaC，从FinOps孵化出OLAP技术栈，之后广泛应用到资源观测、业务洞察
  • 24H2 精益运营，提出ODD，去技能化、运营驱动开发，尝试用低阶人才、维持复杂系统；23H2开始孵化，24H2基本成熟(AGI后暂停)

23

• 方向规划：继SRE OPaS之后，云管分级。SYS放弃了大管家的定位、只Focus在几大件，基建纵向化拉开帷幕
  • 云管分级，SYS放弃资源管家的定位，专注于云管平台、资源服务化(ICSP)；云管分级是OPaS在基建方向的延续
• 团队管理：领域觉醒，OP追求独立价值，不希望再被带节奏、不愿再做架构之余。从这一刻起，我才算 胜任运维TL岗位
  • 领域思维，前提是摆脱低阶粪坑、有精力做高阶思考，之后DDD理论输入，OPaS、FinOps、DIaC、CM体系化产出，为上层的领域理论建设做好了铺垫
• 技术成长：工程质量，引入领域驱动DDD理论，完成工程质量的体系整理。面向传统OPs/低阶Coder，初衷还是培养提拉
• 体系建设
  • 23H1 领域觉醒，开始追求运维的独立价值，不再被带节奏、不做架构之余；分工越来越明，协作却越来越难
  • 23H2 工程质量，系统整理工程质量培养体系，涉及组织、理论、规范、流程、低代码等，1年后达到成熟（事后证明培养不如筛选）

22

• 方向规划：SRE真正落实了OPaS，开始规划驱动、体系化产出；预单模型，推广到业务管理、抽象出业务中心
  • OPaS继续完善，明确技术对象、场景，拆分领域职责(如子网去应用化)，刻意去横向(如项目轮流主持)
• 团队管理：感受到人才梯度制约，尝试强化规则来兜底人，如月度重点附带成长要求(红字)、结果验收升级为独立第三方。部分跳出温情管理的恶性循环，但依然以下级为中心
  • 事后看，直到24年才开始主动淘汰不合格成员，真正摆脱以下级为中心的管理模式
• 技术成长：工程质量，开始尝试左移，包括开发规范、软件工程理论
• 体系建设
  • 22H2 业务建模，预单模型从FinOps延展到应用领域、创造性的抽象出业务中心，业务预单成为资源实例、应用模块/组件集群之后的通用第三级

21

• 方向规划：提出OPaS，步入正轨。问鼎企业职能架构，将OP从横向组织、拉回到纵向思路，纲举目张、自此一通百通
  • 同时，略微意识到 运维被当做架构之余，跨领域擦屁股的事情过多，开始强调运维领域的独立性
• 团队管理：组织建设，以下级为中心，温情讨好、掰嘴喂食、兜底提拉，错把温情待人等同于纵容对事，自己过的很辛苦
  • 同时，目标管理，发展出月度重点(结合周会)、结果验收等规则框架；当时，虽未明确意识到温情待人的弊端，但以实际行动做了弥补、身体很诚实，实践先于理论了
• 技术成长：工程质量，开始拆分工具中台、尝试低代码、引入开源，为OPs参与开发创造条件
• 体系建设
  • 21H2 提出OPaS，21年SRE放弃研发代工的定位，专注于平台工程、运维服务化(IDP)；23年SYS放弃资源管家的定位，专注于云管平台、资源服务化(ICSP)；24年横向解构Toils，OPaS理论建设完成。从提出到完备，OPaS理论建设花了3年时间
    • 横向解构：拆解横向事务 -> 提取通用要素 -> 按纵向目标重组 -> 沉淀纵向能力

20

• 方向规划：尚无方向。基础架构早在20年末就定下了大方向，基本准确、之后长期沿用；反观OP，21年底才初版OPaS、晚了1年。定方向，最重要、没有之一
• 团队管理：理论输入，开启体系化。绿宝书输入了完整的管理框架，个人开始笨手笨脚、但很认真的实践&吸收，从此逐步具备了组织思维。理论建设，起到了提纲挈领的作用
• 技术成长：纵向萌芽。纵向思维，起于20Q4运维团队的细分，SRE/SYS/DEV的分工、推动我以小方向的视角思考问题，康威定律发挥了作用
  • 20Q2时，工作还是项目制，重点工作管理做到了月粒度、分类比较整齐 => 延续了横向思维
  • 20Q4时，OP团队的小组划分基本完成，且之后大体被延续、只有少数微调。小组划分，推动我以小方向的视角思考问题，纵向思维被萌芽
• 体系建设
  • 20H2 管理框架，绿宝书输入了选用育励汰的五步模型，自此组织思维、管理实践缓慢但正向的发育

19H2

• 角色认知：严重错位。19H2延续了单兵模式，尚未准备好做管理。空降接手团队，半年内把所有工作摸了一遍，了解业务+接地气；但，身为TL依然采取单兵模式，主要精力被消耗在了一线上，定方向、带团队两件大事反而没做好。
  • 角色错位，客观原因是做一线+补位消耗过大，管理半径也过大；主观原因是认知不够、能力不Ready，即使重新做一遍、可能也不会更好
  • 犹记得，19H2热情推介滴滴的服务者心态，想以此收获认可，何其可笑。服务者心态、成事的态度，本质是横向思维，什么都热心管、反而什么都不专业
• 体系建设
  • 19H2 横向思维，延续滴滴的运维方法论，主稳定性、代工模式、服务者心态+成事的态度，从19H2持续到21H1。横向思维，有广度有格局、但专业根基过浅，一旦失焦就会被带节奏，轻则过程价值归零、重则既有阵地不保

工作总结-目标反思

25H2@ZYB

• 体系
  • 云管分级
  • 基建AGI
• 管理
  • 退守：人力资源进一步压缩 => 工作被迫向内转、保核心价值。优先做好领域内的事情、以及公司战略/BossDrive的大事情
  • 分工：继续探索领域分工。人力资源紧俏，IaaS/PaaS/SaaS纵向林立，领域间隙相互扯皮。探索解决方案，包括
    • 产生背景：人力压缩，边界收紧、领域间隙相互推诿。挑肥拣瘦，自己吃肉别人擦屁股、以邻为壑
    • 消灭间隙：
      • 固化场景：通过平台工程、消灭一部分领域间隙。如拍搜、直播、宿主、网关等场景
      • AGI编排：原子工具 => AI编排、答疑 => 个性化需求
    • 领域归位：
      • 领域分工：避免越俎代庖。首次发生时，可以顾全大局、业务优先；第2+次，则Push领域归位。BadCase如 职责泄漏(我不疼你先来)，双重标准(上下左右都要适配我)，跨界甩锅(信息上误导瞒报)，白嫖心态(跨级施压、不计代价的攫取)
      • 礼尚往来：面对职责泄露、双重标准，可以主动作为。设计反馈机制，促进公正的相互理解
      • 管理兜底：面对跨界甩锅、白嫖心态，寻求组织协助。先拒绝，打得一拳开；再上升，从更高的位面寻求合理决策
      • 领域切割：如屡次发生习以为常、严重伤害到团队价值，则考虑领域切割、解除或转移依赖关系。如离线基建
    • 事务轮转：不可避免的、分内的横向事务，轮流做、保障公平。如TB主持、项目PMO、答疑等。不设横向专职岗位
    • 消灭分工：运用工程思维、架构组织分工，高内聚、低耦合，最大程度的消灭人和人的内耗(组织工程)。包括，
      • 人类个体是非标准件，不适合协作、但擅长原创。据此，部分场景下：
      • ①明确人类角色：将人类个体定义为原创单元，在独立的小格子中、完成原始创新（高内聚）；
      • ②重构协作模式：用工程化思维、塑造协作架构，推进高标准、低摩擦的机间协同/人机协同，消灭非标准、高摩擦的人人协作（低耦合）
  • 治理：调整认知、重新定治理。初次治理，是建设、不是运营，治理不完、建设不止。提升治理主动性
    • 顺势而为：管理员要认识到治理工作的长期性。特别是服务链路耦合，空间复杂度高、时间周期长，不能幻想一蹴而就、而要顺势而为
    • 有所不为：客户端治理首选搭便车。客户端治理，需要域外实施、周期长&ROI低，谁着急谁推动、不着急则搭便车；反观服务端治理，管理员自主可控、随时作为
• 专业
  • 多云架构：业务的多云架构，质量效果在弱化、治理作用在凸显。技术持续积累，单一厂商的质量相比5年前有很大提升，接近顶级基建（银行、电信、发电厂）
  • 多云资源：基建的多云资源，从小众产品、到常规云管、再到自研组件，云管体系趋于完备，组件自研二开还有较大空间，而AI Coding降低了工程质量门槛
  • 平台工程：运维即服务OPaS，从全局共性、到二级特性、再到个性化满足，平台工程从宏观架构走向精耕细作，AI编排有望补齐个性化环节。二级特性，包括业务场景、组件品类、资源分组等
  • 合规：合规投入显著增加，形成了新的输入。国家护网，基本前提发生变化、内网不再可信，建设目标从守边界、升级到零信任；经营合规，业务&主体的经营压力，扇出到云账号、域名、EIP等技术层，政策有波动、业务有试错；小程序、应用商店、SEO等也在加强各自的合规要求。安全合规，与国际形势同频共振
  • 组织：组织工程，运用工程思维、建设组织架构。筛选合适的人、砸资源做留存，这是技术管理最简单有效的方式。资源不到位、人未长成时，可以辅以制度设计，包括领域分工、目标管理、高阶架构&去技能化、工程质量培养体系，这些原本是很好的管理输入；但随着武汉新人集中入厂，节奏被打破、组织超负荷
  • 其它：成本蜕化到运营阶段；基建AGI转型，方兴未艾、全方位输入，未来可期
• 探讨
  • 协作：厂商协作，产品能力不Ready时，推厂商改造、还是我方适配？基本原则是什么？
    • 不定制。但凡定制必埋隐患，要拥抱主分支、跟随厂商迭代计划，或将我方主张推成主分支。短期便利 vs 长期可持续
    • 有格局。放眼全国全球，在更高的位面上做设计、做权衡，助力整个领域健康发展，而不是只顾小我
  • 决策：信息即权利。观测过于暴露，不但有损决策权(外行干涉)、还加剧了PE压力(暴露更多underlay)，专线方向尤其明显。怎么破？
    • 消除半吊子决策，首先要避免创造出半吊子的人。信息暴露，要把我好度
• 个人
  • 祛魅：互联网应用技术无壁垒。大部分时候，你只需要大声说出新概念、新名词，就能唬住吓退很多人(不明觉厉)，从而在不增加核心竞争力的情况下筑高壁垒。对此，需要有意去神秘化
  • 体验：走不一样的路，看不一样的风景，体验不一样的生活。人生短暂，不要重复

25H1@ZYB

• 体系
  • 精益运营
    • 常态运营：过程管理、结果验收、状态维持，集中治理
    • 数据运营：治理，生产，应用
    • AGI应用：理论，基建，框架，应用
  • 管理框架：去技能化，工程质量；分工管理，例外管理
  • 数据体系：DIaC，OLAP
• 管理
  • [知识体系]分工：继续探索领域分工。人力资源紧俏，IaaS/PaaS/SaaS纵向林立，领域间隙相互扯皮。探索解决方案，包括
    • 产生背景：人力压缩，各团队收紧边界，边界之间是法外之地、相互推诿；挑肥拣瘦，以邻为壑。危害如存而不论，微言大义
    • 消灭间隙：固化场景，通过平台工程、消灭掉领域间隙，如拍搜、直播、宿主、网关等场景
    • 领域归位：按领域分工，避免越俎代庖。首次发生时顾全大局，业务优先；之后，设计反馈流程、促进权责对等。BadCase如我不行你找他(职责泄漏)、我很急你得马上(不计代价)
    • 事务轮转：不可避免的横向事务，轮流做、保障公平，如TB主持、项目PMO、答疑等。不设横向专职岗位
  • [知识体系]例外：标准和例外各有价值。标准，是规模化复用和运营的前提；例外，有利于局部的灵活高效。寻找平衡点
    • 允许例外。除商务、安全、合规等红线外，业务有不入标准体系的权利，运维要有判断和加白的能力；不在体系中则无需治理，身处体系中则必须治理
    • 中台分层。平衡公司和部门的差异化诉求。一级中台管理公司级共性，如基础架构基建；二级中台管理局部共性，如直播架构组(部门)、大数据管理员(PaaS)、前端基建(领域)等
    • 统一模型。统一隔离标准，兼具模型固化、运营质量，路径是 ①元数据标注(建模) ②控增量(准入)、修存量(治理) ③自动巡检、定期审阅(防蜕化)
  • 治理：调整认知、重新定治理。初次治理，是建设、不是运营，治理不完、建设不止。提升治理主动性
    • 长期性：管理员要认识到治理工作的长期性。服务调用链路耦合，空间复杂度高、时间周期长，不能幻想一蹴而就、而要顺势而为
  • 文化：主动而不专业，折腾；专业但不作为，躺平。躺平的蛀虫，是主观的恶意、不可容忍
• 专业
  • [知识体系]横向：解构横向工作，认识到它的相对性、存在性、局限性，并合理转化。包括，
    • 相对性：横纵之分，源于视角。同一事务的横纵属性，随观察者的层级、立场而变化
    • 存在性：横向工作，真实存在。我们眼中的横向事务，往往是高层眼中的纵向目标，高层纵向目标 = Σ(基层横向事务)
    • 局限性：纯粹横向，阻碍积累。离散、碎片化的横向事务长期执行，将导致专业能力稀释
    • 可转化：解构横向，沉淀纵向。思路是，拆解横向事务 -> 提取通用要素 -> 按纵向目标重组 -> 沉淀纵向能力
    • 转型教训：技术生涯由纵向构成的，要建立纵向思维、明确纵向目标，不能沉浸于临时的横向奖励。如运动战过后价值归零、沉浸在琐事无法自拔
  • 技术：技术永远是新的好。运维需要坚守场景，但要更新技术栈，比如K8S。这不是破坏分工，而是自我革新
    • 反面：AGI重复探索是另一个极端。真正革命性的技术，早一天晚一点不会太关键，把时间留给ROI最大的事情
• 个人
  • 思维：回头看很清晰，身处其中、向前看时却满头雾水。需要刻意培养 主动预判的思维体系
  • 执行：发现问题、马上就干。问题是十分的确定性，技术多变、人生短暂，不要等
• 探讨
  • 格局：何为大局观？如何做选择 才算顾全大局？资源有限，无法既要又要还要也要，怎么办？
    • 基建是一种大局。公司级，体量大、标准严，杠杆率高。坚持长期主义+做好基建，是INF价值所在，有利于公司的长期竞争力
    • 特化副作用严重。短期人力ROI小、长期技术熵增大。决策权衡，考虑整体代价、而不是基建或应用层某一方，如RTA、RTC
    • 作为基建一方，要有智慧识别 特化、潜在的功能扩展
  • 协作：架构协作，排期过长、形成阻塞，缺少礼尚往来、相敬如宾。资源有限or倾向不足？如何改善呢？
    • 警惕：对我而言，小侧面上想太多&陷进去、不值当，警惕心智窄化、保持认知弹性
    • 选型：解决方案选型，不但要考虑技术可行性，也要考虑组织的可依赖性 —— 组织架构决定XX

24H2@ZYB

• 体系
  • 数据体系：DIaC
  • 管理框架：高阶打样、去技能化ODD 运营驱动开发
• 管理
  • 分工：继续探索领域分工。人力资源紧俏，IaaS/PaaS纵向林立，SaaS领域间隙相互扯皮。探索解决方案，包括
    • 大局：平衡领域分工和顾全大局。首次发生时顾全大局、保障结果，第2+次发生则要领域归位；首次之后要Push领域归位，如应急后附治理工单
    • 场景：提炼场景、倾斜资源解决大问题，如网关场景(IaaS和SaaS间隙)、流媒体场景(IaaS/PaaS和SaaS间隙)
    • 项目：尝试自主流转的项目管理，在美东迁移事项上效果尚可，难点在于上下衔接；在轻PMO的组织架构下，避免再创造出一个横向角色
  • 例外：标准和例外各有价值。标准，是中台复用和规划化管理的前提；例外，有利于业务的灵活高效。现实是标准和例外的混血，只是偏向某一方的程度不同
    • 标准：中台分层，平衡公司和部门的差异化诉求。一级中台管理公司级共性，如基础架构基建；二级中台管理局部共性，如直播架构组、云产品管理员、成本二次分摊、前端基建接口人、专线泳道等等
    • 例外：除商务、安全、合规等红线外，允许例外发生。业务有不入标准体系的权利，运维要有判断和加白的能力；不在体系中则无需治理，身处体系中则必须治理
• 专业
  • 平台：平台是领域责任的延伸。自助平台代替管理员、服务用户，管理员要为平台效果负责，不能以ToRD自助名义、一放了之
  • 变更：管控模型继续固化，人工审批收敛为组织上级、资源属主、产品管理员三级，工单类型聚化为ToRD自助、ToM内部合规、及少量的ToB中间态
  • 成本：厂商计费越来越精细，规则越来越复杂，涨价蚕食时有发生，红蓝对抗、精细对账
  • 治理：治理验收是人工版的常态巡检，治理验收要明确对象范围、检查方法、验收标准，已完成的治理项应该纳入自动巡检
• 个人
  • 与人为善：大环境持续恶化，积攒多年、被发展掩盖的社会问题开始爆发，焦躁和戾气几乎成了集体人格、一点就着。蛰伏期，更需要主动的与人为善。比如，能用技术和专业解释的、就不要上升到人格，能用愚蠢解释的、就不要用恶意
  • 技术管理：技术上有必要但ROI低的事情，可以尝试用管理解决，比如审批管控、二级管理员；很多时候，管理也是一种架构手段，管理和技术的结合很美妙
  • 重新发明：经常遇到一个现象，自己冥思苦想、创造出来的解决办法，在业界已经有人发明过，抢注原创失败、未免失落；但重新发明reInvent的过程，本身就是完整体系、深度思考、知其所以然的过程，最终效果通常优于拿来主义
  • 成长模型：挑选顺境，持续小赢，不断强化自我实现的预言，这是一个自卑但又心怀梦想的个体的成长模型。相比在逆境中隐忍攻坚，我更愿意在顺境中追求极致；通过持续小赢，不断提高掌控感、强化自我实现的预言，也锻炼快速复原力、降低自卑的影响
  • 认知弹性：在刻苦努力之后，依然愿意接受、那些不受自身控制的事实。比如，职场环境恶化、连生三个儿子
• 探讨
  • 治理：治理是高度危险的变更，H1有ZNS、H2有网关域名，一不小心就是P0大故障；治理工作，尽量顺势而为(如自然消亡)，避免添乱(如H末月不治理)
  • 管理：很多时候，我的创意思维过于发散，没有聚化为实际目标、更缺少进一步落地的动作，让团队成员无所适从，而自己反而觉着下属没有完成好。这一点要改改

24H1@ZYB

• 管理
  • 行业：互联网大张大和的年代已经过去了，这就是大势所趋。就业已经从买方变为卖方市场，管理压力有所降低、但组织厚度也在下降
  • 组织：互备编制被压缩，一个萝卜一个坑成为新常态。用效率换效益，风险可控、但新老更替需要更长周期和耐心
  • 协作：分工边界更突出，模糊处理的内耗开始显著。如火山APM、K8S集群、安全域、大数据PaaS。面对矛盾升级或故障驱动，存而不论、不如当机立断
  • 技术：以容量换质量，先拿到运营价值、再逐步建立专业性的思路切实可行。公共云和开源体系的完善，让技术门槛持续降低，这在10年前难以想象
  • 能力：去技能化，降低人员的专业要求。经历了4+年的集中建设，大部分运营态的事情都可以固化模板、按图索骥，不再单人绑定
• 工作
  • 目标：大马拉小马，用核心事项、牵引体系建设。大的如多云架构、安全合规，小的如CDN多活、存储服务治理，运营如机器管理
  • 项目：假途灭虢，借助大势、顺路治理。基础设施对业务体系的撬动作用、已经进入边际阶段，但基础设施内部还可以继续挖掘
  • 治理：对抗熵增。经历了4+年的演化，自建系统的熵增变得非常显著，如老CMDB、ZNS，代码冗余、逻辑过时、观测失效的情况比比皆是，需要小范围重建
  • 局限：运营思维只能让公司Run下去，专家才能带来质变。以直播img桶黑产为例，成本上两年前就发现BOS下行流量很大，当时以为是业务特点、还特意调高了定价，郭江华来到作业帮后、很快识别出是黑产流量，并最终治理
• 个人
  • 格局：最近1-2年过多的深入细节、规划领域、打磨分工，格局蜕化比较严重；接下来会有意识的恢复，不纠结于低层次的人和事，不踩不争多捧场
  • 领域：满足哪些条件后，公共云厂商就可以完全替代基础架构、直接服务于公司内部的业务RD团队？这个问题非常值得探究，可能就是将来演进的方向
• 探讨
  • 协作：派发治理工单本质是跨团队安排工作，相比业务目标、并没有天然的政治正确性。建议遵循分工原则，①大目标自上而下建立共识、由对方T1/T2安排资源推进，②小目标做到谨慎和必要、完善评估和监督机制，避免浪费
  • 意识：AP和TP很难兼顾。一个人不应该既负责AP又负责AP，长时间负责AP形成懒散的习惯后、再操作TP就容易缺少敬畏，典型如04.10ZNS大故障
  • 创新：可被直接引入、消化的低垂果实已经摘差不多了，接下来就是各种攻坚，考验定力、更考验创造性
• 其它
  • [启发]业务：场景固化本质是运营能力的横向串联，解决方案本质是组件选型的横向串联，两者都是横向串联
  • CND：甲方成本驱动、云市场劣币驱逐良币，CDN节点质量下降在所难免，这就需要客户端做好自动化的选路和容灾，节点质量观测的意义反而不太大
  • 边界：机器套餐是关键的治理边界，它是IaaS和应用的交界面，集成了容量、性能、流控等多重功能。类似的节点还有子网、…
  • 角色：纵向交付者、管理者、提供方，横向解决方案架构师(负责纵向选型)
  • [启发]视角：平台ToM、ToB、ToRD。除ToM、ToRD视角外，运营工具还需要有ToB的第三视角，目前管控、体验都比较差，典型如机型套餐

23H2@ZYB

• 管理
  • 组织：团队模型在变化，从学习组织、转变为军事组织，更看重实效、对成长的容忍度有所降低
  • 分工：人力极致压缩的情况下，各团队都在收紧边界、边界之间是法外之地，相互推诿或被动跟随有损格局；Cloud方向放弃大管家思维，专注在几大件
  • 协作：基础设施中台的自助化转型，不但需要中台封装复杂性、如建设平台+培训接口人，也需要业务RD能接住、如人才能力升级
• 专业
  • 信任：信任是团队效率的根基，坦诚需要投桃报李，这一点Peer做的不好
  • 组件：以需求交付思维做中台、做组件，必然导致失焦 => 在技术生涯的每个阶段，都不应该把横向当做目标
  • 治理：治理要顺势而为、避免刻意为之，一旦遇到服务调用链路，资源/组件升级就不可能太快，借助大项目顺势推动、容忍时效
• 个人
  • 管理：理念宣贯不到位，过于看重刚性制度约束，忽略了文化的软作用，共识效果依赖减1补位、目前看有遗漏
  • 目标：运维中台全面容器化，目标矫枉过正、政治正确，K8S管理集群不支持R单元化、且运营不完善

23H1@ZYB

• 管理
  • 组织：梯度，管理者要为结果负责，但这并不意味着牺牲自己、长期兜底组织缺陷，凯撒的归凯撒、上帝的归上帝
    • 更新记录20260114：终于明确反对粪坑了，终于不再委屈自己，非常正确
  • 文化：人文关怀，领袖力主要靠拉、而不是推，拉力主要是个人影响力 包括专家权力、榜样权力、信息权力，推力主要是职位权力 包括报酬权力、惩罚权力、合法权力，这一点我没做好
  • 技术：工程化、服务化的输入在迅速降低，需要探索新的成长点，如AIGC、纵向
• 专业
  • 规范：IaaS是基础设施最底层、应该保持简单和规范，不应该被PaaS、SaaS的概念入侵；类似安全组打洞的BadCase痛心疾首，后续会加强原则
  • 治理：运营治理有别于服务治理、应尽量避免服务链路改造，一方面服务链路黏性超强、点的改造可能会调动一条链甚至整张网，另一方面服务链路改造周期长、无法快速拿结果
  • 度量：尽量在服务端完成度量、而不是客户端，BOS、CDN提供了正反例证 => 选型，不但要考虑技术可行性，更要考虑协作团队的可依赖性，组织架构亦是架构
  • 领域：领域划分答案不唯一，受限于组织结构、技术实现、业务场景等；领域划分是一个折中权衡的过程，没有绝对正确、只有相对合理
    • 更新记录20260114：规范、治理、度量、领域，说的都是一件事，领域觉醒，OP不希望再被带节奏、不愿再做架构之余
  • 变更：变更管控的初衷是人工管理，这一点早晚会过时；跨场景的自动化串联是新的核心价值，比如服务检查将观测数据从烟囱、推向了体系化，未来可期
• 个人
  • 管理：人文关怀（靠拉不靠推）、情绪控制（组织梯度）这两点做的不好
  • 技术：方向大定，高维成长停滞，只能在小纵向寻求安慰
    • 更新记录20260114：自认高维成长停滞时，其实才刚刚胜任运维TL岗。永远不满足、永远渴望更上一层楼，感谢自己的这份雄心壮志

22H2@ZYB

• 管理
  • 人才梯度：进入精细化阶段后、明显感到人才制约，缺少兼具技术深度、产品理解力的高阶 —— 我个人没有做好人才梯度规划
  • 项目验收：人性不可靠。重要项目，需要设置独立机构、实施监督验收。成本高的问题待解决
  • 项目管理：大项目不设PMO的情况下，谁发起谁受益、就由谁主R；OP不是PMO
• 专业
  • 分层模型：按对象、场景，将基础设施分层为内部云平台ICSP、内部开发者平台IDP，ICSP主纵、IDP主横
    • 运维服务化已经过了矫枉过正阶段、运营管理开始被重新重视，接下来会进入 「运维服务化+运营管理」两条腿的状态
  • 技术裂变：解决方案追求纯粹的K8S原生、造成技术体系裂变，成本转移到平台建设，如DoH、OS、LB、网关等
  • 工程质量：在强压之下工程质量有所提升，但尚未形成意识自觉，监督落地成本挺高 —— 掰嘴喂食是人才筛选问题的延续
    • 更新记录20260114：此时已明确感受到，人才梯度靠筛选、而非培养
  • 秘钥泄露：对象存储静态秘钥泄露风险已经暴露了2+年，STS方案也呼吁了1+年，当前尚无完整解决方案
• 个人
  • 情绪管理：精细化阶段的跨阶指导增多，不胜其弱、情绪化更严重了。目前是双输状态

22H1@ZYB

• 专业
  • 运营文化：这半年高强度的治理、建设，引发了几个大故障，直播等业务开始更加保守；过分强调流程、有点矫枉过正，短期会降低效率，长期会思想僵化，需要积极牵引
  • 规范蜕化：标准化治理完成一波地推后，很容易发生蜕化，比如，新增的域名没有遵循服务治理规范。如何降低维持规范状态的成本，值得关注和探索
  • 工程质量：有接近50%的平台运营事项，是因为前期 功能设计不合理、工程习惯不规范，是没必要的工作量。因此，制定了运维平台的建设规范、逐步完善，运维平台-建设规范
  • 面向终态：工作流自动化系统要面向终态，代码是人写出来的、没有想象的靠谱，必须做好终态检查 比如，几周前，宿主自动销毁 因代码韧性不足、导致检索部分机器退还失败，过了20天才被发现、造成严重浪费
  • 安全域控：当前很多SaaS需求要借助IaaS实现，SaaS理念进化快、但IaaS变动成本高，这构成了两者的矛盾；建议将应用特征剥离、基于服务身份做访问控制，保持IaaS的简单刚性 比如，IP地址规划会因为应用特征、认知迭代而调整，而存量机器的调整远远赶不上这个进度
• 管理
  • 目标管理：「小组周会过月度重点」是最好的目标管理方式，可以因人而异的设置检查点、顺便完成过程辅导
  • 项目管理：重点项目的管理过于宽松、卡位不足，失去了对最坏情况的兜底能力，H2做好关键人关键节点的合理卡位、同时避免挤压下级空间
  • 组织分工：团队成员的认知提升后，对岗位的专业性、完整性提出了更多诉求，可能会带来一些摩擦。比如MQ控制层、CD ToC面 —— H2合理管控
• 个人
  • 管理心态：做到了充分放权，不重复投入、做好关键补位，在组织结构持续扁平的过程中、发挥好自我价值；这是一个煎熬的蜕变
  • 专业成长：之前非常坚持原创，只相信个人的深度思考；这半年逐步意识到，借鉴他人很重要、可以显著提效事半功倍，逐步调整中
  • 思维方式：之前是自下而上、问题驱动的思考，在全局观、趋势把控上有所缺失；H1真正融入了自上而下、规划驱动的思考方式，开始收获

21H2@ZYB

• 专业
  • 低代码: 低代码在降低平台运营包袱方面、效果不错。H2探索了UI组件复用、运维中台、脚本编排、大数据报表等低代码方案；接下来手段扩展到托管、开源、SaaS等方面
  • 公有云: 运维对公有云的认识依然不足。目前主要在使用方面，在网络等小方向有了一些架构性深入；需要站在服务提供方的角度，加深认识、辅助选型。我方对公有云产品演化也形成了一些输入，这有利于我方的架构归一，如变更管控、多路由表、网关流量TopN等
  • 演进的代价: 云原生法外之地、云原生架构迭代、公有云产品迭代，形成了长期存在的异构技术栈、增加了运维的SKU。如，应用网络安全域、EMR/Tair半PaaS形态、AKSK泄漏问题等。从运维管理角度看，贵在统一，需要运维左移到架构&云产品的设计环节
  • 阶段调整: 容器架构的集中建设期已结束，接下来，运维重心转回到运营能力建设
• 管理
  • 导向调整: 容器化、多云容灾等项目，运维横向支持较多、有形沉淀偏少，运动战过后很容易价值归零；接下来要按照OPaS思路、注重有形能力沉淀，工作目标不变
  • 目标管理: 过程管理的方式，从H1的月度总结、调整为H2的月度重点&每周周会过月度重点，聚焦办大事、核心目标完成的都比较好；对一个横向工作较多的团队来说，很有帮助
  • 项目管理: 多个项目因验收不足、出现虎头蛇尾，需要在项目管理上突出验收的重要性。如，RocketMQ主从、安全域隔离、宿主购买自助化等。有些验收，不深入就无法做判断，验收成本很高
• 个人
  • 思维转变: 历时2年，终于跳出一线思维、开始聚焦高阶事项。拥有、失去、再拥有，这个过程挺困难
  • 理论建设: 运维导向调整为OPaS，更关注有形的运维服务能力沉淀。有形沉淀包括 规范、流程、平台、架构等，不仅仅限于平台
    • 运维是有独特价值的领域。值得坚守、值得付出、有出路，我辈应有运维领域自豪感
    • 杀不死你的、终将使你强大。感谢云原生，促成运维领域老树发新枝，是乃运维领域之大幸
    • 业界很多同行不厚道。端起碗吃饭、放下筷子砸锅，一度让运维工作者产生了价值危机，其心当诛
• 探讨
  • 前端架构: 端上监控数据质量差，导致运维建设了CDN平台、但定位能力不可用，投入无产出。前端组织架构，可以有更大的作为
  • 横向组织: 产研横向项目推进吃力，如多云，QA&OP补位不一定合适，缺少技术型PMO团队
  • 岗位职责: 在稳定性方面，业务是第一负责人、SRE是外挂；在DevOps接近达成的阶段、尤其如此。大一统的稳定性职责范围，是否需要调整？更近一步呢？

21H1@ZYB

• 目标
  • 低估了运营的工作量，「建设有余、运营不足」
    • 网络方向，在人力受限的情况下，工区上云、RTC内网推流等项目建设目标不断提高，而投入在生产网络治理和基建上的精力不断被压缩，间接加剧了专线的两次大故障。专线的两次大故障，运维止损动作都造成了二次伤害，本质就是因为投入在运营上的精力过少、路由维护不善
    • 机器方向，没有充分考虑宿主适配方面的运营投入，平台建设的目标设置过高、完成率很低，打击了方向负责人的积极性
  • 高优插入的目标，缺少严谨的目标定义、对齐过程
    • 多云容灾，运维理解的目标需要分多期完成，H1只需完成多云部署，链路治理&演练等放到H2达成；业务认为，做完多云部署后、就能达成多云容灾的效果，不用再担心专线故障、单云异常。运维/架构没有将目标的阶段性，明确传达给业务，预期管理不到位
    • RTC内网推拉流项目，建设目标不够明确。运维大部分时候被具体事项、推着走，缺少全局观，投入大、但参与度低
  • 过程管理不到位，导致「失焦」，沉浸在事务性工作中、无法自拔
    • 平台建设方向，缺少过程监督，原来的站立会、月度总结等制度全面停摆，60%的开发精力都花在了老平台的修修补补上，而类似CMDB、统一控制面等重点目标都没有达成
    • 机器管理方向，同样是过程管理不到位。前几个月，没人催促、晃晃悠悠的就过去了，直到06月、有了监督，平台建设才开始有进展
    • 运营工作当然是一个消耗因素，但通过合理的过程管理，确实能找回很多时间精力、投入到重点目标上
• 专业
  • 云服务管理基建不足，平台建设严重滞后，限制了专家能力的发挥
    • 除机器管理之外，存储、子网、域名、CDN、安全组、账号等云服务还停留在原始的「邮件审批+手工操作」阶段，不但影响到了运维效率，甚至还成为了外审的短板。云服务运维管理平台，已成为核心短板，H2作为重点方向、加大投入
    • 对应的，公有云对运维的输入不足。当前以服务交付、运营为主，虽然也邀请专家来做一些领域经验分享，但在公有云产品设计原理、选型、专家能力培养方面尝试还比较少
  • 自建中间件方向投入不足，专业能力建设过慢，以MQ最为明显
    • 运维投入不足。当前只有嘉宾1个人负责多个服务，日常运营任务重，无法聚焦、勉强维持，特别是MQ、可能再次成为火药桶。在无法引入专家的情况下，运维内部酌情调度人力、到组件方向
    • 架构缺陷发现晚、治理慢。以RocketMQ多云架构为例，初期运维/架构认识不足，到后期变成了阻塞项。问题驱动的模式，在基础服务的架构建设方面，效果不佳；目前寄希望的演练，也比较依赖运维的投入
  • 专业的人，做专业的事；做事，要以形成「专业能力」为目标，勉强维持不可取。作业帮发展到现阶段，这个要求已经很明朗
    • 更新记录20260113：纵向思维呼之欲出
• 管理
  • SRE职能定位，相比20H2成长路径已逐渐清晰、走上正轨，SYS/SA/DEV的成长路径尚不明确、需要高优搞定
  • 尊重组织的「熵增定律」，找到合理的延缓措施。如，
    • 自研平台，老系统运营需要的投入越来越多，上半年已经占到了60%开发精力。目前看，要合理裁剪目标、控制下用户的预期，同时引入低代码开发模式(如引入开源)
      • 随着时间推移，自建平台的功能、数量不断增加，用户对平台的个性化需求、体验、稳定性要求也越来越高
    • 角色互备，在纵向专家领域比较困难。因为，子方向差异大，强行互备有损专业性。基本可以认为，投入不足、则无法互备
    • 需求管理，跨小组的问题反馈、问题闭环已经无法自然达成，需要类似双周例会机制来强制推进。小团队的沟通福利，已经基本耗尽
      • 以作业平台为例。前期，平台体验不太好，SRE提不起兴趣，在没有外力推动的情况下，双方很容易陷入恶心循环，「平台不好用、所以SRE不再使用、不再提建议，平台没有需求输入、体验一直无法改善」。运维内部启动双周需求沟通会后，鼓励SRE提建议、监督平台改进，效果不错
  • 「因人设岗、因人设目标」，得不偿失，脱离团队现状
    • 监控方向，因负责人的兴趣，设定了智能监控的探索项目。这个目标，过分追求业界的先进技术，既没有考虑当前的人力情况，也没有照顾到类似CDN监控的紧急痛点。脱离了团队现状的目标，伤害性极大

20H2@ZYB

• 专业
  • 业务运维继续按照既定思路、稳步加强，围绕稳定性主题，在现状学习、服务治理、流程规范、工具建设等方面有所进展；同时，云原生打破了传统思路，带来了一定的岗位忧患
    • 容器接入: 接入环节SRE未掌握关键节点、事前缺抓手+事后很被动
    • 容器运维: 容器运维也尚未形成套路
    • 技术运营: 运营环节过度ToC弱化了运维的全局控制力(特别是网关)
    • 资源运维在网络方向的专业性提升很大，机器管理工具也有所进展，但整体上对云服务的专业性偏弱、工具支撑不足，后续需要继续加大投入
    • 工具建设继续围绕业务、资源运维两个方向展开，合作紧密、工具产出效率高，但人力一直没有得到有效补充，压力过大 - Cancel
• 团队
  • 看方向: 未能及时梳理、宣贯团队职能定位。云原生背景下，团队价值调整升级，未能及时梳理、宣贯，造成部分成员的困惑，参与感弱; 输入不足
  • 带团队: 关键岗位未建立起融容能力。1-1、激励管理动作缺失，-2放权硬着陆，对成员诉求了解不及时，导致新人留存差、老人有怨言; 关键岗位B角色缺失。接下来，需要HR介入、一起加强留存、合理HC
  • 做事情: 向上透传较多，向下同步不足。个人精力在工具体系上投入较多、在项目推进+业务沟通投入减少，部分关键工作向上穿透严重(依赖心理)。接下来，找到关键路径，加强业务关联
  • 专业性: 部分方向专业性定位尚不清晰。延续了常规稳定性运营的意识和方式，做到可运营状态后就不再继续深入了。接下来，针对部分云服务和组件，在OKR、日常实施中，落地对专业性的要求
  • 沟通: 缺少晓聪-1范围的沟通机制，技术方案同步、关键问题沟通不顺畅
• 目标
  • 优点: KR里程碑+月度总结，对保障OKR实施的正向作用大，可以继续保持和加强
  • 不足: KR设定偏饱和，留给高优插入、12月的buffer不足，造成成员心理压力大
  • 不足: 对OKR工具理解不全面，未加入团队建设目标，后续设定着重补全
• 个人
  • 转变慢。经历了云原生的困惑期，未能及时主动求助、导致负面情绪影响较长
  • 未能有效发挥管理职能，2021需要加强

20H1@ZYB

• 团队
  • 成员持续优化，新人潜力兑现、老人有所提升
  • 营销/供给、运维开发子方向，待补充高阶
• 专业
  • 事务性工作基本流程化或转移，部分日常还未工具化
  • 专业深度和广度的矛盾还比较突出，需要继续投入精力解决好
• 个人
  • 部分工作分解不到位，思考总结投入不足
  • Q2后期情绪管理出现问题

19H2@ZYB

• 优点
  • 1.扛住压力。完成运维资源向一课方向合理倾斜，完成双活、暑秋、寒春等专项；接手资产管理的一线工作，保障了该方向的平稳过渡（Q2末核心人员离职）；指导平台建设，完成几乎零起步工作
  • 2.认真负责。工作认真、细致，先后经历一线历练、资产管理补位、应用运维补位、平台建设补位等工作
  • 3.团队向好。制定和坚持了严格的招聘规则，新入职的员工基本具备当前可用、长期有潜力的特点，保障了团队的长期竞争力
• 不足
  • 1.工作方向转变滞后。在完成运维日常支持调优后，未能及时转变思路、将重点经历投入到自动化建设方面来，直到被外部push后才有所觉悟；资产管理一线环节，迷失到细节中、没有及时拔出来
  • 2.团队招聘太过严苛。招聘标准过严，人员没有及时补齐，导致Q3、Q4出现了较大的运维支持压力。
  • 3.系统管理技能缺陷。个人和团队在sys系统管理方面存在知识缺陷，且未能通过招聘等形势提前补齐。目前在sys的系统性层面有所改观，待仍然有大的优化空间