波仔
☁️ 第四章 构建云服务的技术
📄 一句话概括

这一章讲的全是技术，最后一条落在组织上——因为技术换了，谁干什么活也必须跟着换：装机器、配网络的活变少了，写代码管配置、定策略的活变多了；而【服务管理】说的是这件事的另一面：越是把基础设施交出去，越要靠约定把边界说清楚，把【谁管什么、承诺多少、钱算谁的】写在纸上。

📝 本节和前面几节的关系

这是第四章的最后一节，也是唯一的非技术节。教材把它放在章末，意思很清楚：技术讲完了，得回头看看用技术的人怎么办。

它回应的正是前面所有内容的落点：容器和编排（4-7）让部署变成声明、IaC（4-8）让环境变成代码、DevOps（4-9）让两边共担指标——这几件事合起来，原来的岗位分工就被重新画了一遍。

一、先看岗位上发生了什么

技术换了，人做的事也必然跟着换——四类以前天天动手的岗位，现在做的东西完全不同了。

二、动手 Demo：四类角色的过去与现在

看到什么算成功：

==================================================================================================
【Demo 20】企业和组织的动向：技术变了，组织跟着变
==================================================================================================
  这一章讲的全是技术，但最后一条落在组织上——因为技术换了，
  谁干什么活也必须跟着换。

  角色                    过去主要做什么                现在主要做什么
  --------------------------------------------------------------------------------------------
  基础设施运维            装机器、换硬盘、配网络        写代码管配置，管云上的资源
  数据库管理              装库、调参、做备份            设计数据模型与访问控制
  网络管理                配交换机、拉线                定义策略与网络分段
  服务台                  接电话、手工处理请求          自助化，人只处理例外
  --------------------------------------------------------------------------------------------
  服务管理（教材 4-20 的关键词）说的是这件事的另一面：
  越是把基础设施交给外部，越要靠【约定】把边界说清楚。

  要约定什么              什么意思
  --------------------------------------------------------------------------------------------
  服务目录                我们对外提供哪几项服务，各自的入口在哪
  服务级别（SLA）         每项服务承诺到什么程度，达不到怎么办
  责任边界                哪些事服务商管、哪些事我们自己管
  变更管理                谁可以改什么、改完怎么通知、出事怎么回滚
  成本归属                这笔资源费算在哪个部门头上
  --------------------------------------------------------------------------------------------
  最后一行在云上格外重要：过去买了服务器就是那个部门的资产，
  现在资源是谁开的就记谁的账，所以【谁来管这笔账】必须是明确的。

读结果：

三、服务管理为什么在云上更重要

【服务管理】这个词听起来像流程官僚，但它解决的是一件很实际的事：当一件事不完全由自己控制时，怎么保证结果可预期。

云上的情况正好是这样——你的系统跑在别人的机器上。于是必须提前约定清楚六件事：

要约定什么 不约定会怎样
服务目录 出了事不知道该找谁、走哪个入口
服务级别 承诺是模糊的，事后各说各话
责任边界 出事时互相推，谁也说不清
变更管理 对方半夜改了什么你不知道
成本归属 账单来了没人认领
退出与迁移 想走时发现数据拿不走

最后一行是常被忽略的一条：在不在一起时的条件，要在还在一起时谈定。数据以什么格式导出、有没有费用、要多久——这些如果不写进合同，等到分手那天才发现，代价不可控。 这也是 2-11 讲【看不见的地方靠问和写】时那条主线的延续。

范围也别理解窄了：服务管理不仅是对外部服务商，对内同样适用——内部的基础设施团队给业务团队提供的，也是一种服务。写清楚【我能提供什么、承诺到什么程度】，是内部协作效率的关键。

30 秒实验

打开你们（或任意一家）公司内部的服务台或 IT 支持页，做一件事：

看有没有【服务目录】——也就是一份列明【我们提供哪些服务、各自的申请入口与承诺时间】的清单。

如果没有，说明 IT 还处在【被动响应】的状态：谁打电话就处理谁的事，优先级靠嗓门大小。如果有，你会看到每一类请求都有对应的时限——那说明它已经把内部协作当成了服务来管理。这个小观察能很快看出一个组织的 IT 成熟度。

常见误区

  1. 错误：云把 IT 的活变少了，所以 IT 团队可以缩编。——纠正：总工作量不一定减少，但内容变了。动手装机的活少了，但成本治理、权限管理、合规审计、架构判断的活多了——而且这些活更难、更需要经验。所以现实里经常出现的情况是：运维人数少了，但多了【平台工程】【成本治理】这类以前不存在的岗位。

  2. 错误：用了公有云，安全和管理责任就交给服务商了。——纠正：责任是被切开的，不是被转移的。服务商负责【设施和平台】那一半，账号、权限、数据分类、访问控制永远是你自己的（3-5 里讲过这条分割线）。所以云上出事，多数落在【配置和管理】这一侧——这也正是服务管理存在的意义：把【你负责的那部分具体是什么】写清楚、检查表化。

  3. 错误：服务管理就是买一套工单系统，把流程电子化。——纠正：核心是【约定】，不是【工具】。工具只是载体——如果没有先把【提供什么、承诺多少、谁负责】想清楚，那套系统里跑的就只是一堆没人看的单子。判断标准是：出了事能不能立刻说清【这该谁管、SLA 是多少、现在是否达标】 ——能，说明有服务管理；不能，工具再多也没用。

  4. 错误：内部团队不需要服务管理，那是给外部服务商用的。——纠正：内部更需要。因为外部有合同约束，内部全靠默契——而默契会随着人员流动消失。写清楚【基础设施团队提供哪些服务、申请流程是什么、响应时限多少】，最大的受益者其实是业务团队：他们不用再猜【这事该找谁、大概要多久】。这也是【平台即产品】这个流行说法的实际含义。

自测三问（点开对答案） 1. 【成本归属】这一条为什么在云上变成了一项必须提前约定的管理事项？ —— 因为**云计算把【采购】变成了一件随时能做、且不需要审批链的事**。传统模式里，买一台服务器要立项、要走预算、要有资产登记——**这一整套流程本身就是成本控制**；而在云上，开一台虚拟机可能只需要点几下，**钱是月底从账单里冒出来的**。所以【谁开的资源算谁的账】必须在事前定好，否则会出现【没人认领的支出】。**这是把控制点从【购买前】移到【使用后】的必然结果。** 2. 为什么角色变化的共同规律是【从操作变成设计】？ —— 因为**云把【操作】自动化了，但把【判断】留给了人**。装机、配网络、做备份这些动作，现在都由代码或平台完成——**只要有人描述清楚要什么**。而【描述清楚要什么】这件事，恰恰需要知道业务要什么、成本怎么算、风险在哪。**所以技术门槛降低了，判断门槛提高了**——这也是为什么说【云计算不淘汰人，但它重新分配了人的价值】。 3. 为什么【退出条件】要在合作期间就谈定？ —— 因为**谈判筹码随关系变化**。在用得好、还打算续约的时候，对方有动力给你一个合理的导出方案（这是留住客户的一部分）；而当你已经决定要走、且矛盾已经出现时，**导出数据就变成了对方的筹码**。所以这是典型的【在最不需要的时候谈最需要的东西】——**和备份要在数据还在的时候做、账号权限要在人还在职的时候理清，是同一条规律。**

相关笔记