作者归档：admin

GPT-4 发布了，关于 AIGC 产品上线前后技术管理者要注意的五个重要事项

发表回复

GPT-4 于 2023 年 3 月 14 日发布。目前 GPT-4 没有免费版本，仅向 ChatGPT Plus 的付费订阅用户及企业和开发者开放。

如比尔盖茨在 reddit 回答网友提问时回答时说的：「AI is the big one. I don’t think Web3 was that big or that metaverse stuff alone was revolutionary but AI is quite revolutionary」，我们可能又到了一个历史性的转折点。

现在各家企业，包括 Google、微软，以及国内的 BAT 等大厂都在大量投入，一些中小厂也在垂直的应用赛道拔城攻寨，作为一个技术管理者一定会面对这样一个洪流，在洪流之中我们需要注意什么呢？

如果你所在企业要上线 AIGC 的产品，或者已经上线 AIGC 的产品，以下的五个重要事项需要特别注意。

1 安全

安全是产品的生命线，特别是对于 AIGC 产品来说，没有安全守护，不仅仅是产品玩完，甚至会连累其它产品甚至公司存续。

1.1 内容安全

这里内容安全的定义是指 AIGC 生成内容影响产品本身存在的领域。

在国内与内容安全相关的场景包括涉政、色情、性感（性感和色情在内容安全中是不一样的）、暴恐、违禁、恶心、涉价值观等。其中每一项都需要检测，部分项出现问题甚至会关站和约谈。

在 chatGPT 大火后，网络上有各种和 chatGPT 相关的段子，特别是一些场景下，对输入措辞的调整或多次尝试相同的提示很敏感，只要稍作改写，就可以以另一种方式回答出来。

据最新发布的 GPT-4 的 OpenAI 工程师们们说，GPT-4 的训练在去年 8 月完成，剩下的时间都在进行微调提升，以及最重要的去除危险内容生成的工作。由此可见内容安全是一个多么重要且复杂的事情。

GPT-4 在 RLHF 训练中加入了一个额外的安全奖励信号，通过训练模型拒绝对此类内容的请求来减少有害的输出。奖励是由 GPT-4 的零样本分类器提供的，它判断安全边界和安全相关 prompt 的完成方式。为了防止模型拒绝有效的请求，团队从各种来源（例如，标注的生产数据、人类的红队、模型生成的 prompt）收集多样化的数据集，在允许和不允许的类别上应用安全奖励信号（有正值或负值）。这是 OpenAI 的工程师在训练 GPT-4 时做的一些努力。

GPT-4 现在是闭源的，模型本身我们做不了什么。

除了 GPT-4 ，还有许多的 AIGC 的模型，并且更多的人只是作为一个应用开发方来实现一些功能。

除了在训练时对模型本身危险内容生成的去除，在技术应用侧，我们可以考虑如下一些方面：

  1. 接入内容安全审核平台，在输入和输出两个层面进行双重过滤。公司大的接自己的，公司内没有的接第三方，依靠审核平台的积累，规避掉涉政、色情等风险极大的情况。
  2. 实名可追溯，类似于工厂里面的批号跟踪，对于用户上传图片、文字或视频、使用 AIGC 生产出来的内容、传播的内容进行跟踪，有系统支撑后台的查询和追溯，在后台中注意对用户敏感信息的保护，保持脱敏的逻辑。
  3. 控制传播，控制传播一方面是在功能层面保证传播的内容是在上面安全审核平台的前置约束下进行，另一方面在传播进行多级防控，比如播放量达到不同的级别进行不同规格的检测，如播放量达到 10 万，需要重新进入审核等等。

在互联网行业，内容安全一直面临着挑战，各内容平台不断提升对于内容安全的治理能力，随着 AIGC 的发展，内容爆炸式的增长，内容安全的挑战将会更大。

1.2 虚假信息

在对 chatGPT 深度体验后，往往会生成一种「一本正经的胡说八道」的感觉，甚至它会编造一些事实或者不存在的东西出来回答。对于模棱两可的问题，chatGPT 通常会猜测用户的意图，而非让用户澄清问题。

举个例子，我在 chatGPT-3.5 中问： 「有没有什么现成的库可以检测图片清晰度，对原图和 avif 图进行清晰度检测」，它回答了三个库可以，Sharp、ImageJS和 Pica

我接着问：「 Pica 的什么方法可以检测」，它告诉我 quality 方法可以，并给出了详细的示例，从代码上来看，像那么回事，并且代码前面的引入，输入的格式转化都没有问题，有问题的只是没有 quality 方法而已。

又或者你随便取一个书名，问他是谁写的，比如我的问题是： 「《不想开车的夜晚，我在听歌》这本书是谁写的」，它的回答是：「 “不想开车的夜晚，我在听歌” 这本书的作者是中国作家韩寒。这本书是一本散文集，收录了韩寒的一些散文作品，其中包括《像少年啦飞驰》、《三重门》、《我所理解的生活》等等。这本书出版于2002年，是韩寒的第一本散文集。韩寒是中国当代著名的作家、音乐人、导演和投资人，他的作品包括小说、散文、音乐和电影等多个领域，深受年轻读者和网民的喜爱和追捧。」

除了 chatGPT 以外，图片或视频生成领域有更多的虚假信息，如诈骗团队利用 DeepFake，通过截取马斯克在 TED 采访的视频，并为其配音，为的就是推出 BitVex 比特币诈骗平台。诈骗分子还伪造了方舟投资（Ark Invest）CEO 凯瑟琳·伍德、以太坊联合创始人查尔斯·霍斯金森等多位币圈名人推荐BitVex的视频。另外，2021 年初光是靠 DeepFake 技术换脸马斯克喊出「给我一个币，我给你两个」的骗局在一周内就达到 24.3 万美元，诈骗总额高达 3000 万美元（约人民币2亿）。

诈骗团伙以及不法份子使用 AIGC 恶意使用，甚至滥用，引发新型的诈骗、色情、诽谤、假冒身份等违法犯罪行为。 AIGC 让其效率更高，鉴别难度更大。这样可能会引发人们对于个人身份的盗用，冒用，以及在网络上，或在元宇宙中数字身份安全的担忧。

以上是在 GPT-4 出现之前，在 GPT-4 出来后，情况有所改变，如前面个问题：「《不想开车的夜晚，我在听歌》这本书是谁写的」，GPT-4 的回答是：「很抱歉，我无法找到与《不想开车的夜晚，我在听歌》这本书相关的作者信息。这本书可能不存在，或者没有足够的知名度。如果您能提供更多信息，我会尽力帮助您找到相关内容。」

技术在进步，会越来越好，但是我们仍然需要结合实名制、内容安全检测等手段，我们只能尽量减少虚假信息在平台的产生和传播。

1.3 模型安全

现在 AIGC 内容生成对于我们来说是一个黑盒子，我们无法完全预知其过程和结果。我们所能做的是控制模型的参数和模型的数据输入，这里可能会导致安全问题。

算法的公正性和透明度。AI 系统的决策往往是基于其算法的结果，但是，如果这些算法存在偏见或不公平的因素，将会对用户的权利和利益造成损害。因此，AIGC 需要确保 AI 算法的公正性和透明度，避免对用户造成不公平的影响。

  • 对模型的攻击：通过某种方式向模型中注入恶意样本、有毒数据或有误导性的数据，来破坏模型；或者以某种方式篡改或操纵模型的训练数据，以达到改变模型输出的目的。
  • 模型后门：在模型的训练中，攻击者通过修改模型的训练数据和权重信息使模型学习到了隐藏的规则，以达到放置后门的目的（我也不知道怎么实现）。举个例子，假设有个开源的项目不想让人商用，于是采用了 GPL 的协议，但是如何判断有人商用了呢，于是在项目生成的模型中隐藏一些规则，比如某些特殊的输入能显示和特定的结果，以举证。比如「左耳朵耗子」在 Twitter 上分享的「百度的“文心一格”AI生成图片：“一只爱国的猫”，看来不但政治不正确，而且可以推测后面用的图片训练集的来源也不是自主可控的」，那只猫身上的国旗是美丽国的。不过现在你无法生成了，因为在输入层面做了限制，现在输入只会显示「请您更换输入后试试~」，这也就是我们前面说的在输入层面做一些控制。

除了模型本身的安全问题，对于模型衍生的个人隐私保护，数据安全和标准，甚至后面可能会出现的模型病毒等等都需要持续关注起来。

2 容量

AIGC 产品在面对大量用户使用时，可能会面临以下容量问题：

  1. 存储容量： AIGC 产品生成的内容包含了大型文本、视频、图像等多媒体数据。如果用户数目众多，这可能需要大量的存储空间。假设用户生成的这些内容都是放到公有云上，随着用户的增加，这些内容将会成为一个巨大的成本，因此我们在项目设计之初就考虑存储容量的问题，给每个用户的容量，总的容量，以及存储的时长，因为成本是随着时间而变化的。
  2. 处理容量： AIGC 产品处理大量数据，包括数据的采集、整合、分析和后期制作处理等多个环节。因此，AIGC 需要具备高质量的计算设备和计算能力来支持项目，将应用的各个环节结合起来，处理更多最终输出结果。如果计算能力不足，则可能会给用户带来等待时间过长的使用体验，增加流失率。
  3. 带宽容量： AIGC 产品生成内容的访问请求峰值会在高峰期不断攀升，这需要具备良好的带宽容量来实现。如果网络峰值超过供应时，将影响用户体验和产品稳定性。 因此，就需要整合具有强网络连接性和容量传输能力的网络设备，包括高带宽和低延迟的数字通信方式，例如光纤和高性能互联网符合AIGC产品的要求。
  4. 内容审核容量：AIGC 产品生成的内容需要进行审核和精细化调整，以确保内容的准确性和完整性。这需要大量的人工审核，提供符合要求的人选加入审核容量的组合当中。此外，随着 AIGC 的规模发展，产品审核过程的效率和质量也需要考虑如何优化。

在应对容量问题时，AIGC 产品需要全面优化和规划系统架构、数据处理和存储、计算和运维等方面，以实现产品的高可靠性和高性能。同时，需要持续跟进技术发展和创新，以保持 AIGC 产品的竞争力和创新性。

基于这些考虑我们在应用开发过程中需要考虑以下系统的实现：

  1. 用户级的容量限制，包括存储容量，存储时长，使用次数等等。
  2. 用户试用灰度，如邀请机制，分批次邀请用户进来，以控制容量的发展，不仅仅是存储、还有处理容量和带宽的容量。
  3. 接入多个第三方审核平台，在增加灾备的同时，增加内容审核的容量。

3 成本

对于大模型，一般的企业是没有能力开发的，这种情况我们一般是接第三方的接口。

以 OpenAI 为例，3.1 日，OpenAI 开放了 ChatGPT 的 API 接口，成本优化了 90%，百万 token 只需要 2 美元，并且提炼 otken 能力也大幅优化。新上的 GPT-4 要贵一个数量级，从 0.002 到 0.06，涨了 30 倍。

此外，OpenAI 还提供了图像生成和编辑的服务，如 DALL·E。这些服务的价格取决于图像的分辨率。例如，1024×1024 的图像每张 0.02 美元，而 256×256 的图像每张 0.016 美元。

更多详情见官网： https://openai.com/pricing

在国内也有一些厂商的提供了完整方案报价，大概是 0.1 到 0.13 每张图。

除了接入 API，有时我们也会基于开源的模型微调后上线自己的服务，这部分成本主要是训练的算力成本和上线后的 GPU 机器。以 ControlNet 模型为例，在公有云上，一台带有 v100 显卡的机器也就能跑一个大模型，且单台机器只能同时为一个用户提供服务。而这样一台 v100 的机器一个月的原价为 7000 多。

不管是调用第三方的 API 还是自行构建模型服务，对于创业公司来说，成本都挺高的。

如果想在 AIGC 中创业，从一开始就需要想好商业模式和变现手段，并且对于免费用户需要从一开始就限制其试用频率，以控制成本。

从应用工程角度，我们大概可以做以下的一些事情：

  1. 排队系统，在成本方面主要是应用于自己搭建的服务，其主要是在用户体验和成本之间寻找一个平衡，通过排队的方式将用户的请求量消峰填谷，以尽可能提升机器的利用率。
  2. 限频限额，对每个用户在使用次数或产出物的量上做限额，以防止恶意的攻击或者某个用户大量占用资源的情况。在限额方面我们一般可以采用对使用次数，如做图次数，或者对产出物的数量，如生成图片的数量或生成文字的数量等等。可以是日限或者总量限制。
  3. 预约系统，提高用户的使用门槛，仅针对目标用户发放资格，减少用户量，提升用户精准度的同时能控制成本。
  4. 存储限制，第 2 点的限制主要是针对使用的，如果产品有存储的需求，那么在应用上需要对存储空间的大小或者存储的时长做一些限制，最好是在商业化的逻辑里面把这块加上，因为存储的成本是一个递进累加的成本，随着产品的发展，其成本会越来越大，如果生成的内容中有视频，且你有几百万上千万的用户，这将是一个非常大的成本。

以上主要是应用开发领域的成本，除了这些，其数据成本也是非常大块的成本。而数据是人工智能的基础，没有数据就没有模型。AIGC 需要大量的高质量的数据来训练模型，比如文本、图像、音频、视频等。这些数据的获取和处理是一个巨大的挑战，需要投入大量的时间和金钱。

一方面，数据的来源可能不容易找到或者不免费。比如想要生成游戏场景或者角色，就需要收集各种类型和风格的游戏素材；想要生成影视剧本或者小说，就需要收集各种类型和风格的文学作品；想要生成音乐或者歌曲，就需要收集各种类型和风格的音乐素材。这些数据可能涉及版权问题，需要付费购买或者授权使用。

另一方面，数据的质量可能不够高或者不一致。比如想要生成逼真的人脸图像，就需要收集各种角度和表情的人脸照片；想要生成流畅的语音或者歌声，就需要收集各种语言和口音的语音样本；想要生成合理的对话或者故事情节，就需要收集各种场景和情感的对话或者故事文本。这些数据可能存在噪声、错误、重复、缺失等问题，需要进行清洗、标注、对齐等处理。

因此，在 AIGC 中使用现有数据是一种常见而有效的方法。通过利用公开可用或者自行采集整理好了格式统一且质量较高且数量较多且符合目标任务需求且无版权争议（例如：Common Crawl） 的数据集来训练模型可以节省很多时间和金钱。

4 法律法规和版权

4.1 法律法规

2022 年 11 月 25 日，国家网信办、工信部、公安部联合发布《互联网信息服务深度合成管理规定》（以下简称《规定》）。其中提出，深度合成服务提供者和技术支持者提供人脸、人声等生物识别信息编辑功能的，应当提示深度合成服务使用者依法告知被编辑的个人，并取得其单独同意。《规定》自 2023 年 1 月 10 日起施行。

该规定的第五章第二十三条，对「深度合成技术」做了规定：「利用深度学习、虚拟现实等生成合成类算法制作文本、图像、音频、视频、虚拟场景等网络信息的技术。」，这也就是我们所说的 AIGC 的范畴了。

在《规定》的第六条、第七条、第十一条等对服务提供主体责任进行了明确的定义，具体包括：

  • 不得利用深度合成服务制作、复制、发布、传播法律、行政法规禁止的信息，或从事法律、行政法规禁止的活动。
  • 建立健全用户注册、算法机制机理审核、科技伦理审查、信息发布审核、数据安全、个人信息保护、反电信网络诈骗、应急处置等管理制度，具有安全可控的技术保障措施。
  • 制定和公开管理规则、平台公约，完善服务协议，落实真实身份信息认证制度。
  • 加强深度合成内容管理，采取技术或者人工方式对输入数据和合成结果进行审核，建立健全用于识别违法和不良信息的特征库，记录并留存相关网络日志。
  • 建立健全辟谣机制，发现利用深度合成服务制作、复制、发布、传播虚假信息的，应当及时采取辟谣措施，保存有关记录，并向网信部门和有关主管部门报告。

将上面的条文翻译成技术上的点就是要构建以下的系统或服务

  1. 用户实名注册及管理系统。
  2. 数据安全及敏感信息管理系统和体系。
  3. 内容安全管理系统，这里我们常规会采用第三方的服务，而不是自己开发。

4.2 版权

AIGC 的版权一直存在争议，其根源在于 AIGC 模型的形成和完善依赖于大量的数据训练，而用于训练的数据往往包含受版权法保护的内容。AIGC 这种不同于传统的创作方式，目前尚未有明确的法律规定和司法裁定来界定其版权归属和保护范围。

2023 年 1 月 23 日，美国三名漫画艺术家针对包括 Stability AI 在内的三家 AIGC 商业应用公司，在加州北区法院发起集体诉讼，指控 Stability AI 研发的 Stable Diffusion 模型以及三名被告各自推出的、基于上述模型开发的付费 AI 图像生成工具构成版权侵权。

这应该算是全球首例知名的 AIGC 商业化应用领域，算法模型及训练数据版权侵权案。其主要争议点在于当前国内外对于 AIGC 获取与利用版权作品进行算法训练是否合法存在诸多争议，尚无立法和司法层面的明确共识，并且对于模型训练过程中利用版权作品的方式、利用行为的版权定性仍有待分析明确。

在中国，计算机软件和作品的著作权属于开发者或者相关机构，而现行的《著作权法》框架难以直接认定人工智能或电脑算法为作品的作者。但是现阶段各界对于人工智能技术创作物的著作权保护整体上呈现积极的态度，主流的司法实践持相似的立场。AIGC 版权保护的是使用 AI 系统的人，不是 AI 本身，其保护的前提还是使用 AI 创作的人，在创作过程中付出了智力或创造性的劳动。

目前，一些机构和个人在使用 AIGC 作品时，通常会尽力寻找并遵守相应的版权规定和道德准则，尊重原作者的知识产权，同时也会尝试探索 AIGC 版权的可行性和保护方式。

我们需要持续的关注版权方面的进展。

对于版权保护我们可以做如下的一些事情：

  • 数据授权和许可：在使用受版权保护的数据进行模型训练时，尽量获取数据所有者的授权和许可。这可以通过签订合同、购买许可证或加入版权组织等方式实现。
  • 数据脱敏和匿名化：在使用受版权保护的数据进行模型训练时，尽量对数据进行脱敏和匿名化处理，以降低侵权风险。例如，可以删除文本中的作者名、作品名等敏感信息，或将图像中的人物、地点等特征进行模糊处理。
  • 版权标识和归属：在发布和传播 AIGC 生成的作品时，明确标注作品的版权归属和来源。例如，可以在作品页面上添加版权声明、原作者名和许可证信息等。
  • 遵循道德准则：在使用 AIGC 技术进行创作时，遵循行业道德准则和社会公序良俗。例如，不要使用 AIGC 技术制作和传播违法、侵权、淫秽、暴力等不良内容。

5 模型的偏见性

现在大家常用到的 AIGC 技术的核心都是在大规模数据集上预先进行训练的模型，大多数的使用者都是在特定领域或垂直场景下进行微调。这种预训练模型，对比完全由人工规则控制的专家系统来说，预训练模型就像一个黑盒子。没有人能预知其生产出来的内容是什么。

预训练模型的偏见性通常来自训练数据集中的样本分布不均或者存在系统性的偏差。比如：

  • 在 chatGPT 模型中的语言性偏见，中文的内容语料只占了 0.1% 不到，更准确来说应该是 0.09905%，从而使得使用中文的效果远不如英文。
  • 2.14 日情人节前夕发布的 ControlNet 模型，在测试过程中发现其会生成较多的性感卡通类图片，一些没有问题的照片或者词语都能生成极度「性感」的图片，比如痛苦这个词语。
  • 对于时间的偏见性，模型只能了解其生成之前的情况，或者说只能了解其数据集中的信息，在其生成后就没有信息了，除非快速迭代模型。
  • DALL·E 2 具有显著的种族和性别刻板印象。

除了以上的例子，还有在性别、地域、文化等的偏见性，这些都是因为训练得到的模型并不是非常可控的，模型可以看做对训练集分布的一个拟合。那么反馈到生成模型中，训练数据的分布便是影响生成内容的质量最重要的一个因素。于我们可以采取一些措施来规避将模型的偏见展示给用户。

  1. 数据收集阶段：收集更多多样化的训练数据，以确保训练数据集具有平衡性和代表性，对训练数据进行分析和筛选，排除可能引入偏见的因素。
  2. 模型训练阶段：在微调阶段使用公平性指标，从而评估模型在不同群体中的表现是否公平和平衡；不断监控和更新模型，及时发现并纠正偏见性问题。对一些特定的任务，可以使用迁移学习等技术，以减少偏见的影响。
  3. 产品应用阶段：通过人工或者基于深度学习的模型判断生成的内容是否具有偏见性，以规避一些极端的场景。

我们在上线 AIGC 产品时一定需要深刻的理解其偏见性，及时使用一定的措施规避或者减少其偏见性。

想起网上看到的一句话：「在这个历史性的转折点，只能向前走，不能往后看，过往都被冲得看不着了。」

技术管理者应有的 4 种基本思维模式

发表回复

在看文章之前先思考两个问题：

  • 人和人的差别究竟在哪？
  • 人和人之间为什么会有差别？

在各种场合我们经常听到这样一句话：「听懂了很多道理，却依然过不好这一生」。 这里有两个逻辑，一个是知行合一的逻辑，另一个是人的成长在于是否超越了昨天的自己。

今天我们聊一聊作为一个技术管理者应该要有的 4 种基本思维：掌控者思维、杠杆思维，终局思维，闭环思维

掌控者思维

在聊掌控者思维之前我们先看一下掌控者思维的反面：受害者思维。

受害者思维又称为弱者思维，有受害者思维的人在任何时候都会把自己当作一个受害者或弱者，极端者会把整个世界都投射为「伤害者」，「都是别人不对，都是别人对不起我」。

受害者思维是一种思维定势，其本质上是一种忽视自己的主观能动性的行为。

在《乡村爱情 13》里面，王木生是老总儿子，富二代，但是干啥啥不行，还总是给自己找借口，说大环境不好，其他没这背景的都比他强。赵本山饰演的他爹王大拿就教训他：「自己没能力就说没能力，怎么你到哪，哪都大环境不好，咋，你是破坏大环境的人啊？」

这就是比较明显的受害者思维，也就是我们常说的「甩锅」。 受害者思维不仅仅只有这一种表现，在《拆掉思维里的墙》里面，作者总结了 5 种受害者思维的表现。

  1. 推卸责任，保住面子： 上面王木生就是明显的例子，还有像一些网上的评论说的「便秘都怪地球没引力」都是类似的表现。在这种情况下，受害者思维就会认为自己没有责任，不需要承担责任，相信地球没引力，相信大环境不好……
  2. 安心做坏事：这种表现就是为自己的行为找到一个自洽的逻辑，让自己有一个完美的故事，从而在做坏事的时候能心安理得。比如 2001 被判死刑的「杀人魔头张君」（实施团伙抢劫，犯故意杀人罪 2 2次，致 28 人死亡、22 人重伤）在 2001.4.17 一审审理结束后对公众说的话：「我还要向没有枪的受害者和你们的家庭说声‘对不起’，现在想起来，以前有些事情确实做错了，但我没办法，因为我要生存。」
  3. 让我们一起分享凄惨故事会：寻找同伴，和他们分享你的受害过程，在他们那里得到安慰。比如有个女孩失恋了，她的闺蜜会陪她喝酒，说男人没有一个好东西；
  4. 用受害获得同情和帮助：第 4 种和第 3 种有些类似，其区别是上面是通过群体得到安慰，得到是一种情感或者心理上的安慰，而这种是更直接的帮助或者说利益，如我们在职场里面看到的一些人会假装自己不会，从而让热心的同事帮忙解决，自己偷懒，或者在路上我们看到的一些乞丐，可能他们的收入比你想象中多很多；
  5. 自我伤害，绑架他人：这种就更极端了，生活中常见于情侣分手，某一方说，你要是离开我，我就自杀，或者电视剧中的男主站在女主楼下淋雨以求得原谅或者求得表白成功。

如此种种，这些可以让你有短暂的快乐和安全感，但是慢慢就会失去自信、勇气以及自我改进的能力，就会真的变成一个受害者，一个弱者。

我们活在这个尘世，很多事情已经无法掌握，如古罗马哲学家爱比克泰德(Epictetus, 约55～约135年)所说：「我们登上的并非我们所选择的舞台，演出并非我们所选择的剧本」，如果连我们自己也无法掌控，让自己的快乐、成功都掌控在别人手里，这会是怎样一个光景呢？

当你带一个技术团队的时候，当你的团队遇到问题的时候，当你的下属遇到他认为过不去的坎的时候，当发生线上事故的时候，当老板怼到脸上的时候，你会怎么办呢？

当一个受害者吗？是大环境不好？是技术太难？还是坏人太多？

不，绝对不是这样，一个技术管理者应该是强于面对现实，敢于直面问题，像汪涵在我是歌手第三季总决赛面对大型事故时所说的那样：「没事儿不惹事，事儿来了也不要怕事」，以一种掌控的状态来扛起事情，解决问题。

这就是我们所说的掌控者思维，一种强者思维，一种充分发挥自己主观能动性的行为。

掌控者思维的核心思考是：「如果把所有经历过的事情重新倒推一遍，所有条件都不改变，只有自己改变，你能否得到一个更好的结果呢」

掌控者思维是从责任心，自我成长，主动改变等方面来提升一个技术管理者的修养，以达到自我的精进。 并且不管什么情况，你都可以负全责。只要你愿意，你就可以做得更好。

除了不怕事，负起责任，还有一些是我们必须要做的。

  1. 学习，提升自己的认知，把自己从知道自己不知道变成知道自己知道，换句话说，保持有计划的学习；
  2. 自省，持续的自省，比如当你有一件事做得不好，自我反思一下哪里做得不好，下一次如何改进，或者更深入一些读一些相关的系统的书，写一篇文章或文档来复盘，掌控自己，从卷自己开始；
  3. 计划，凡事预则立，不预则废，如下棋一般，走一步，算三步，把事情想在前头，如美国首席数据科学家 DJ Patil 所说流传很广的那个便签上的话：「Dream in Years. Plan in Months Evaluate in Weeks. Ship Daily. 」
  4. 知行合一，只有做到，才是真的知道。

当然，做一个掌控者会累一些，但是与自由相比，累又算得了什么呢？

杠杆思维

阿基米德说：「给我一个支点，我就能撬起整个地球。」。

一个优秀的人，都有「杠杆思维」，懂得利用杠杆原理，以较小的付出，撬动更大的回报。这里我们所要说的是杠杆思维中的团队杠杆。

当我们从一个开发变成一个技术管理者时，就不再是一个人在战斗了，你的主要责任就不再是写好代码，而是「使众人行」。

时间对于每个人都是公平的，一个人一天都有 24 小时，它是有限的，而我们所面对的这个世界，工作这些都是无限的。

在一个健康经营的互联网企业中，需求也是无限的，而开发同学的时间都是有限的，除了优先级，我们还能做什么呢？此时有人会说：加人啊。是的，加人。但是加人不是随便加的，他有一个底层逻辑，这个就是今天我们要说的团队杠杆。

团队杠杆的本质是叠加效率，人的时间是有限的，而事情是无限的。

什么是团队杠杆？

通过团队，团队的管理者确定好方向，通过良好的机制和人才梯队，系统化成功的路径，叠加个体的优势，创造出远超个人贡献总和的价值，让 1+1>2，这就是团队杠杆。

既然是杠杆，就一定有一个支点，咱们的支点是什么呢？

对一个团队来说，其支点是已经达成了共识的目标和价值观。

目标是什么，是方向，是团队成员能看到的远方。

为什么是达成了共识？是因为只有达成了共识才能保证目标的统一，才能有意愿，有内在的动力去做事情,才能起到杠杆的效果。

目标和价值观只是最基础的，对于一个团队来说，不同的时候其支点也会不同。

  • 在野蛮生长的团队中，核心岗位上的同学的能力提升是主要支点，这里的核心岗位上的能力提升有两层意思，一个是培养员工，给他们训练的机会，培训，从而快速成长；另一个层面是考虑换一个人，当你这认为这个岗位上的员工的能力、态度差不多到顶了，那就可以考虑用更好、更合适的人来替换，这里的逻辑是选拔大于培养。
  • 在快速扩张的团队中，流程和效率是主要支点，通过流程提升协同的效率，通过流程让新人快速融入团队；
  • 在稳定发展的团队中，标准和系统是主要支点，当业务趋于稳定，通过标准和系统固化操作，以系统代码流程和人工。

有了支点，我们就需要开始寻找杠杆，对于一个技术团队来说，团队的杠杆有多大，由人决定。 一个团队里面的人是怎样的，人才梯队是怎样的，人才密度是怎样的？

像麦肯锡，每年都会从全球各个顶尖大学，比如哈佛大学、斯坦福大学、麻省理工学院等，招一大批刚毕业的年轻人，不管是不是商学院毕业的。这些绝顶聪明的年轻人，就是麦肯锡充沛而有效的「团队杠杆」。

对于我们一个普通的互联网创业公司来说，作为一个技术团队的负责人，在有限的范围内选出符合要求的同学，同时尽我所能的带好团队。对于如何来带好团队，我们可以从如下 4 个大的方面来

  1. 信任：不管是平级，还是上下级，信任是必须品，通过良好的沟通，多次的合作，一起的奋斗达成信任，这样才是一个好的团队；
  2. 习惯：管理者以身作则培养团队良好的工作习惯，如做事闭环，分级处理，不越红线等等；
  3. 标准：制定能落地的标准，让大家知道什么是好的，什么是对的；
  4. 能力：流程机制决定事情的下限，人才梯队和个人能力决定事情的上限，管理者要帮忙团队成员成长，发现他们的短板，坦率的沟通并提出改进期望，提升成员的技能，以达成更好的结果。

以上带好团队的表述有些虚，但是是这么个逻辑，各团队各公司术法不同，但方向一致。

用好团队杠杆，一个人走得更快，一群人走得更远。

终局思维

什么是终局思维?

所谓终局思维，是指从终点或者未来的某个时间节点出发，回看现在所做选择，并进行推演的一种思考模式。

这里可能有人会问，什么是终局，是否有终局？这就有点哲学的味道了，先假定有吧，至少在某个未来的时间段是会有一个确定的终局。

我们经常听到人们感叹，如果这辈子能够再来一回，很多错误就不会犯，很多人也不会错过，这算是终局思维的一种表现。只是这个终局思维是等到了终局再提起，有些晚了，我们可以再早一些。

我们在做一件事情的时候，如果能思考一下这件事情的最终达成的目标，或者把最终的形态在脑海里面勾画出来，以终为始，站在未来看当下，修正当下正在做的事情，那么这件事情成功的概率可能就不一样了。

终局思维有 4 个核心点：

  1. 认清方向，所谓的终局思维，一定是你要知道终局是什么，一定要有目标有方向；
  2. 拉长时间周期看问题，在一个较长时间维里来反复推演的逻辑；
  3. 从历史或者更宏观的层面看问题，不局限于当下，不局限于眼前的一亩三分地，把视野拉到历史长河等更大的层面；
  4. 反推机制，终局思维中非常重要的点，从未来反向推演现在要做什么，或者从现在推演未来怎样。

终局思维有什么用?

当一个企业的老板大概知道了未来是什么样子，又能不断地判断和复盘自己的能力，他自然就有了非常强的战略驱动能力，也非常敢为未来投资。

当一个技术管理者知道了团队未来是怎么样的，又能反思当前的情况，从未来形态反思当下的状态，他自然就知道现在最重要的是做什么。

当一个开发同学知道了自己在职场上想成为什么样的人，又能反思自己提升自己，他自然知道现在应该做什么，应该学什么，应该选择什么样的团队，什么样的路。

但是，这里一定会有一个痛苦的过程，甚至不止一个，可能是一直在痛苦中，折腾自己，反思自己，提升自己，一直有危机感，一直在学习中。

心理学研究说，人类对于外部世界的认识可分为三个区域：舒适区（comfort zone），学习区（stretch zone），和恐慌区（stress zone）。我们反思自己、提升自己的过程基本都是在学习区，人只有在学习区的时候，才会是进步的时候。

闭环思维

经常听到人人说：「凡事有交代，件件有着落，事事有回音」，这是典型的闭环思维，是一个职场人的必备思维。作为一个技术管理者更应该具备闭环思维，因为这将是你带团队的核心逻辑之一，它强调责任、敏感性和团队协作，是使众人行的必备。

以「逆向」的逻辑来推演一下，假设你带的团队成员都具备闭环思维，将是什么样的场景？

  • 高效率：闭环思维要求在一定时间内，无论任务完成的效果如何，都要认真、负责的反馈给发起人。这可以帮助团队及时发现问题并加以解决，从而提高工作效率。
  • 强协作：闭环思维需要团队成员之间相互配合，洞察干系人每个阶段的需求，并在截止期内给对方反馈。这可以增强团队协作，提高团队的工作效率和成果。
  • 靠谱：闭环思维要求做事靠谱，做事清楚明白，不会出现意外差错，就算出了问题也会提前告知，让对方可以启用方案 B。这样的技术团队会让人觉得可靠和可信，提高团队在公司中的信任度。
  • 好形象：闭环思维是一种良好的职业素养，可以让你和你的团队建立良好的职业形象。在职场中，「闭环思维」不仅仅说明了一个员工拥有完成任务的能力，还体现出「良好的合作意识」，这样的你会让上级、兄弟部门觉得很「靠谱」，能够放心的将工作交给你和你的团队。

那么如何做到闭环思维呢？

闭环思维有两层逻辑，一个是完整，即有完整的闭环，做事情的时候需要考虑事情的起点、目标、影响因素和结果，明确需求和关键点，以及可能遇到的问题，在过程中设置检查点，让事情可控；另一个是主动反馈，在我们完成一项工作或参加一项事情，不管执行效果如何，都要及时将结果反馈给发起人。

第一层逻辑我们可以使用 PDCA 环来辅助达成，第二层反馈逻辑还是需要刻意去练习，甚至给自己设置一些任务提醒来达到反馈的目的，并且在反馈时尽量做到 STAR 的表述。

番外

最近 chatGPT 一直在火，于是就今天的题目我问了 chatGPT 一些问题：

  • 技术管理者必备的4种基本思维模式
  • 技术管理者必备的思维模式
  • 技术管理的四种思维
  • 技术管理者必备的4种思维

大概的答案如下：

openAI 的回答

问：技术管理者必备的思维模式

作为一名技术管理者，以下是一些必备的思维模式：

  1. 系统思维模式：技术管理者需要具备系统思维模式，能够理解和处理复杂系统的各种关系和相互作用，从而在整个系统中发现问题并提供解决方案。
  2. 创新思维模式：技术管理者需要能够持续地推动创新，寻找新的解决方案并将其应用到业务中，从而实现业务目标。
  3. 问题解决思维模式：技术管理者需要能够分析和解决各种问题，包括技术问题、组织问题和人员问题等。
  4. 客户导向思维模式：技术管理者需要关注客户需求和体验，从客户的角度出发思考问题，为客户提供高质量的产品和服务。
  5. 团队合作思维模式：技术管理者需要具备团队合作意识，能够有效地管理和领导团队，激发员工的潜力，协调各种资源，实现业务目标。
  6. 风险管理思维模式：技术管理者需要对业务中可能出现的风险进行预测和管理，制定相应的应对措施，确保业务的可持续发展。
  7. 数据驱动思维模式：技术管理者需要依据数据进行决策和管理，从数据中发现问题和机会，制定相应的战略和计划，提高业务效率和效果。
  8. 学习和成长思维模式：技术管理者需要保持学习和成长的态度，不断学习新知识和技能，从他人的经验中汲取营养，不断提高自身的领导能力和管理水平。

phind 的回答

问：技术管理者必备的4种基本思维模式

答案1

作为技术管理者，必备的4种基本思维模式如下：

  1. 系统思维：技术管理者需要具备系统思维，可以将复杂的问题分解为简单的部分，然后逐一解决。例如，当公司需要开发一个新产品时，技术管理者需要思考每个阶段的具体步骤，确定每个步骤的时间表和责任人，确保整个过程的顺利进行。
  2. 创新思维：技术管理者需要具备创新思维，可以在技术方面寻找新的解决方案，以提高公司的竞争力。例如，当公司需要开发一项新技术时，技术管理者需要思考如何利用现有技术来开发出更好的产品，或者如何开发出全新的技术来满足市场需求。
  3. 沟通思维：技术管理者需要具备良好的沟通能力，可以与员工、客户和其他部门进行有效的沟通。例如，当公司需要与客户沟通产品需求时，技术管理者需要了解客户的需求，并将这些需求传达给开发团队。
  4. 领导思维：技术管理者需要具备领导思维，可以激励员工，推动项目进展，达成公司目标。例如，当公司需要完成一个重要项目时，技术管理者需要领导开发团队，确保项目按时完成，并向管理层报告项目进展情况。

技术管理者不仅需要具备以上4种基本思维模式，还需要具备自我驱动、架构把握、目标管理等核心能力，才能胜任管理岗位。在实际工作中，技术管理者应该灵活运用这些思维模式和能力，不断提升自己的管理水平。

答案 2

根据多个来源，以下是技术管理必备的四种思维和其他相关思维模型：

  1. 抽象思维：这种思维能力可以帮助技术人快速抽取面对问题的关键要素和本质，从而更好地分析和解决问题。
  2. 系统思维：这种思维能力可以帮助技术人将问题看作一个整体，理解各个组成部分之间的相互作用和影响，从而更好地进行系统设计和管理。
  3. 创新思维：这种思维能力可以帮助技术人寻找新的解决方案和创新点，从而更好地推动技术进步和发展。
  4. 逻辑思维：这种思维能力可以帮助技术人分析和推理问题，从而更好地发现问题根源和解决方案。

除了以上四种思维，以下是其他常用的思维模型：

  • PEST分析：这是一种常用的管理咨询框架，可以帮助企业从政治、经济、社会和技术等多个角度分析市场环境和竞争对手，从而更好地制定战略和决策。
  • PDCA循环：这是一种管理模型，可以帮助企业进行持续改进和优化，包括计划、执行、检查和行动四个环节。
  • SMART原则：这是一种目标管理模型，可以帮助企业制定具体、可衡量、可达成、有意义和时限的目标，从而更好地推动业务发展。
  • STAR法：这是一种面试技巧，可以帮助面试者回答问题更具体、更有条理、更有说服力，包括情境（situation）、任务（task）、行动（action）和结果（result）四个要素。
  • 5W2H法：这是一种问题分析和解决模型，可以帮助企业和个人从五个W（what、why、who、when、where）和两个H（how、how much）多个角度分析问题和制定解决方案。
  • PERT 技术：这是一种项目管理工具，可以帮助企业规划和安排整个项目行程，跟踪实施阶段，从而更好地控制项目进度和成本。

总之，技术管理必备的思维能力和模型是多种多样的，需要根据具体情况选择和应用。除了上述思维能力和模型外，还有很多其他的思维工具和技术，需要技术人员不断学习和掌握，以更好

答案 3

根据多个来源的信息，以下是四种技术管理必备的思维能力：

  1. 抽象思维：这种思维能力可以帮助技术人员快速抽取问题的关键要素和本质，从而更快地理解问题和解决问题。例如，当面对一个新的编程语言时，抽象思维可以帮助技术人员快速理解其核心概念和语法规则。
  2. 产品思维：这种思维能力可以帮助技术人员更好地理解用户需求，并将技术解决方案转化为实际的产品。例如，一个架构师需要了解产品的功能需求，以便设计出最佳的技术架构来支持这些需求。
  3. 创新思维：这种思维能力可以帮助技术人员不断创新，寻找新的解决方案和技术。例如，当面对一个复杂的技术问题时，创新思维可以帮助技术人员找到一种独特的解决方案，从而提高效率和质量。
  4. 商业思维：这种思维能力可以帮助技术人员更好地理解商业环境和商业需求，以便为企业提供最佳的技术支持和解决方案。例如，在设计一个新的软件系统时，商业思维可以帮助技术人员理解客户的商业需求，并设计出最佳的系统架构来支持这些需求。

除了以上四种思维能力外，还有其他常见的思维模型和方法可以帮助技术人员更好地管理和解决问题，例如：

  • PDCA 循环：这是一种常见的问题解决方法，包括计划、实施、检查和行动四个阶段，可以帮助技术人员系统地解决问题。
  • SMART 原则：这是一种有效的目标设定方法，包括具体、可衡量、可实现、相关和时间限制五个要素，可以帮助技术人员设定清晰的目标和指标。
  • 5W2H 法：这是一种问题分析方法，包括什么、为什么、谁、何时、何地、如何和多少七个问题，可以帮助技术人员全面地分析和解决问题。
作者：潘锦
链接：https://juejin.cn/post/7203880677195661373
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

聊聊企业级 SaaS 产品稳定性

发表回复

在我们聊企业级 SaaS 产品稳定性之前我们先定义一下这里的企业级 SaaS 产品是什么，稳定性是什么。

1. 企业级 SaaS 产品

根据各家研报的定义，企业级 SaaS 是指以企业客户为服务对象，通过 SaaS 交付模式，向企业用户提供管理软件的服务。主要具有网络供应，集中托管、按需供应及服务化四大特征。

  • 网络供应 是指 SaaS 产品大多部署在云端，每个客户使用产品的方式，通过互联网进行分发；
  • 集中托管 是指使用「多租户构架（Multi-Tenant）」，依靠对数据库分区/分表（其中的一种实现方式）来实现隔离操作，逻辑上隔离，物理层面是共享的。对私有化部署的客户，会单独处理；
  • 按需供应 是针对中小企业的需求，中小企业的需求在短时间内有较大幅度的变化，特别是一些快速增长的发展类企业；
  • 服务化 是指 SaaS 企业按月/年付费的商业模式，其核心的增长逻辑在于持续服务的能力，这也是 SaaS 企业的核心竞争力，第一次交付产品只是整个客户生命周期的起点。

以上 4 个特征可以让客户享有开箱即用、较低成本、实时更新以及按需订阅的优点。

1.1 SaaS 产品和 C 端产品的区别

SaaS 端产品面临复杂的业务场景和用户场景，因此进行细节设计时，必须关注建模、抽象、角色、权限等问题。除了使用者本身的功能需求以外，还需要考虑管理者或者决策者的管理需求。C 端产品面临的场景相对单一，并且使用者是相对独立的单个用户，因此不用关心角色、权限管理，而要关注用户的体验，需要在交互设计上投入很大精力。除此之外，在付费决策、使用场景、专业度的期待值、安全等方面都有不同：

  • 付费决策人不同，C 端产品的使用者和决策者基本重合，而 SaaS 产品的决策者和使用者绝大部分可能是不同的两波人；
  • SaaS 产品绝大部分在工作场景，而 C 端产品大部分在生活或娱乐场景；
  • SaaS 产品关注功能 > 体验，需要能帮助他解决工作场景里面的问题，体验反而是其次；
  • SaaS 客户花了钱，对稳定性要求会更高，对于问题的容忍度会变低，甚至有些要求会写到合同中去，当出现可用性问题时会有赔偿的情况；
  • SaaS 客户对于专业服务的期待值不同，他们对于问题希望是有更专业的人员和更专业的方式来解决，如包括专业的服务，专业的产品，专业的流程，专业的人员，专业的交付，专业的客情维护和沟通话术；
  • SaaS 客户对于产品安全、数据隐私、隔离等方面有更高的要求；
  • SaaS 产品交付只是整个客户生命周期的起点，核心的增长逻辑在于持续服务的能力；
  • SaaS 客户更看重服务过程中 SaaS 企业的专业表现。

1.2 隔离性

以隔离性为例，企业级 SaaS 产品对于隔离性的要求也不一样，我们看一下 AWS 对于隔离性有更细致的要求，总结起来有如下 3 点：

  1. 隔离不是可选项，是产品的基本要素，系统需要确保有解决方案来提供隔离性；
  2. 身份验证和权限管理不等于隔离，它只是隔离的一个环节，在这个环节后面需要构建对于开发人员视野之外的隔离策略，并作为默认项；
  3. 隔离不等于要求完全的物理隔离，可以基于共享资源模型的多租户逻辑，对于有特殊要求的可以提供物理资源级别的隔离。

思考一下，为什么会有隔离性的需求

SaaS 服务往往会服务于多家企业，企业与企业之间的数据需要完全隔离，不同的企业其量级，需求各有差别，当一家企业使用出问题时不能影响另外一家企业，比如某个企业触发了一个 BUG，这个 BUG 不能影响别的企业的使用，或者一家企业的数据量特别大，不能因为家企业的数据计算影响别家企业的计算，特别是有一些离线计算逻辑的时候。我们在使用云服务的时候也会遇到宿主机超卖的问题，这其实也是一种隔离性做得不到位的情况。

以上这些是我们了解到的一些关于 SaaS 企业的定义和特性。

做产品稳定性的建设和我们平时做一个需求一样，先要搞清楚需求方是谁，需求的价值是什么。

企业级 SaaS 的稳定性需求来自于哪里，是行业，政府，还是客户，还是公司要求？

比如金融行业，有一些业务模块对于稳定性的要求来自于政府，是不能打折扣的，做不好，可能会影响公司生死。又比如在内容相关的行业，如果对于一些涉政、涉黄等内容没能控制住，任其泛滥，可能会导致产品的下架，这里的要求同样来自于行业和政府。

回到我们企业级 SaaS 产品的稳定性，这个需求来自于购买了我们服务的客户，SaaS 产品解决的是工作中的问题，是生产资料的一种，当生产资料不可用的时候会对其工作产生破坏，比如依赖于某个数据分析系统的结论，但是数据分析不能用了，老板要求的报告就出不来，此时又不可能重新拉数据分析，只能等，这样可能就会影响用户第二天的的汇报工作等等，后果可能是丢了客户，甚至丢了工作。如果我们长期不稳定，稳定性也将会影响公司的生死。

相对于 C 端用户的数据，SaaS 的数据显得尤为重要，其作为企业资产的一部分，具有有形的价值，甚至是企业的核心资产，比如做代码管理的 SaaS 服务，对于一家软件公司来说，代码就是其核心的资产，如果因为 SaaS 服务数据丢失，或者泄漏，对于企业来说将会是影响企业生死的大事故。

2. 产品稳定性

前面更多的是聊需求和需求价值，接下来我们聊一下产品稳定性具体是指什么，以及如何做好产品稳定性。

产品稳定性包括三个方面：产品功能的稳定性、数据的稳定性和系统服务的稳定性。

2.1 产品功能的稳定性

产品功能的稳定性可以从功能的上线、变更和下线三个方面来看。无论怎样，我们在做产品功能的变更时都是以减少打扰用户为前提。

2.1.1 产品功能的上线

产品功能的上线，在上线每个功能的时候都要慎重，想不清楚宁可不做，在我们习惯了互联网的敏捷模式后，快速迭代，快速试错成为我们常规的工作方法，但是对于 SaaS 产品来说，敏捷不再是最重要的点。

对于我们的客户来说，更重要的是解决一个场景的问题，或者说解决他们工作中的问题，能提升效率。在我们上线一个产品功能的时候应该能讲出用户故事。

当有某个产品功能能够解决用户问题后，就不要经易改变其逻辑，因为用户已经可能将这个产品功能做到了工作的 SOP 里面。

2.1.2 产品功能的变更

产品功能的变更包括产品的版本规划、功能发布变更。

对于产品功能的规划或版本管理，需要有特定的节奏，让用户习惯你的节奏。对于每个版本，做好了，做稳了，把版本发布前前后后的事情做扎实了再慢慢发布出去，给客户一个接受的过程，一个较轻的落地。并且能让客户能快速找到变更了什么，给客户安全感，如 Saleforce 有一个发布说明（R）https://help.salesforce.com/s/articleView?id=release-notes.salesforce_release_notes.htm&type=5&release=240

有节奏的发版，比如 Canvas LMS(一个学习管理平台) 是每个月的每三个星期六正式发版(Release)，每周的周三灰度部署(Deploy)，用户可选择性预览使用灰度部署的功能 canvas release

又如 Salesforce 一年就三个版本，命名为 Spring, Summer,Winter spring-22-release 这里不仅仅是发版，发版只是技术层面的逻辑，这里的更多的是产品的逻辑，需求左移。

2.1.3 产品功能的下线

产品功能下线，在下线的时候要考虑到如何承接这部分用户的需求，尽量能有替代方案来承接。

变更管理没有银弹，我们能做的是控制节奏，以 SaaS 的逻辑来控制变更管理，这里的管理除了代码的发布，还有线上环境的变更，线上配置的变更等等，强调一点：在用户的使用期间，不要动任何线上的东西，包括代码，配置，环境等，一切以不影响用户工作为前提。

当产品功能变更，或者进行大版本升级时充分考虑用户的操作习惯以及学习成本，可能你面对的用户在电脑上学会一个操作是很难的一件事情，甚至需要有人专门来培训。每一次的产品变更就需要其培训负责的同学从头来培训一遍。

就算用户量少，也要进行灰度，减少影响范围。

2.2 数据的稳定性

数据的稳定性是企业级 SaaS 产品特别重要的一点，只有确保客户数据的安全性才能长久提供服务，其主要包括以下 4 点：

  • 数据不会乱，主要是指当用户习惯了一些数据的逻辑后，不要轻易的打乱，如一些默认排序规则，一些分类逻辑之类的；
  • 数据不会丢，数据备份，长期存储，对于上传的文件，在满足成本要求的基础上，尽可能的存下来，如果实在不能存了，也放一个地方，给用户一个出口可以方便获取得到；
  • 数据不会泄漏，这块是数据安全的范围，比较常见的问题是不同的租户数据串了，或者不同的用户数据串了，这里原因可能是代码问题或者架构问题。还有更严重如我们在网上经常看到的被拖库，如前段时间上海的数据泄漏
  • 数据可追溯，对于用户的操作，有详细的日志，知道数据从哪来的，要到哪去的，当出了问题可以追溯。

2.3 系统服务的稳定性

系统的稳定性包括系统的可用性和性能稳定：

2.3.1 系统的可用性

系统的可用性指在一个给定的时间间隔内，对于产品系统来说，总的可用时间所占的比例。我们一般用 SLA(Service-level Agreement) 约束和描述可用性，其常用指标如下：

  • MTBF：Mean Time Between Failure，平均故障间隔时间
  • MTTR：Mean Time To Repair，平均恢复前时间
  • MTTF：Mean Time To Failure，修复前平均时间

关于可用性，所要做的事情太多，简单几个字，可用性治理就包括了度量、线上管控、架构治理和研发管理等等。

在互联网行业有个对于线上事故 「 1-5-10 」的原则，即 1 分钟发现，5 分钟定位，10 分钟恢复，如果能做到这个程度，算是及格了。而且这只是针对可用性线上事故处理 SOP 中的一个逻辑，我们要做的事情还有很多。

落到常规建设中，监控、压测和演练，三个经常要做的操作，但是实际上我们仅仅关注了监控的一部分及压测的一部分。

关于系统可用性我们可以做如下一些关键的步骤：

  • 测试并跟踪当前的可用性：先有度量，诊断我们可用性的状态；
  • 将手动流程自动化，自动化部署过程：相信代码比人更靠谱，特别是针对重复性事务；
  • 维护和跟踪管理系统中的所有配置：所有和线上相关的都是线上环境，而线上配置的变更往往是高危风险地带；
  • 构建线上问题的快速恢复能力：包括但不限于灰度发布、A/B 实验环境，允许快速更改并进行实验，并且保证如果出现了问题可以轻松回滚；
  • 将线上问题和系统可用性作为技术团队的核心绩效指标：管理逻辑中有一个核心点你考核什么，大伙儿就会注重什么，人多数是趋利的；
  • 以不断改进应用程序和系统为目标：反脆弱、不能因为怕变更带来的风险而停止改进；
  • 服务分级，制定严格的 on-call 机制，对于核心服务需要在分钟级响应并处理。

2.3.2 系统的性能稳定

系统的性能稳定指在满足用户功能可用的基础上，稳定性能，同时在一定程度上帮助可用性的建设。

稳定性和可用性相比，除了关注系统可以无故障地持续运行时间，故障发生的频率，还会关注性能劣化趋势等等。稳定性更关注系统在给定条件下的响应是否一致，行为是否稳定。稳定是对可用性的进一步的要求。

上面聊完了企业级 SaaS 产品和产品稳定性，接下来我们聊聊如何长久的做稳定性的治理，如董宇辉老师在直播间谈到初恋时说的：「你不就图我吗?更长久的图我吗?我懂」，对于稳定性我们也是想长久的图。而且还是用科学的方法系统来图。

3 基于风险模型的稳定性治理

考虑到稳定性治理是一个长期的事情，且是需要持续迭代的，如果只是靠人来推动，当人员变动或者工作重点变化时，可能稳定性相关的事情就会陷入停滞状态。

此时我们可以把所有的稳定性问题抽象出来，形成风险，我们通过系统性的持续的识别风险，并制定对应的风险缓解计划和应对计划，应该是可以较好的控制整个系统的稳定性情况。

管理风险的第一步是识别并理解系统中已有的风险。识别、标记并对已知的风险排列优先级，这就是风险模型所要做的事情。

尽管我们总是想消除风险，但是这样做的成本通常是无法接受的，无论是从实际成本还是从机会成本的角度来看都是如此。我们肯定有更重要、更加需要以客户为中心的事情要做，这些事情对我们的客户、公司来说都有好处，而不是从应用程序中消除你所知道的每一个风险。

管理风险涉及对每个风险评估两个值：风险的可能性和风险的严重性。一般来说，严重性是风险发生时的成本，而可能性是风险发生的概率。一个不太可能发生但是会对应用程序造成非常严重影响的风险，不一定是你想要消除的风险。同样，一个很可能发生但是对应用程序影响很小的风险，也不一定是你想要优先消除的风险。但是，一个很可能会发生并且会导致严重影响的问题，是你需要优先解决的风险。

3.1 风险管理

在聊风险模型之前，我们先聊一下风险管理。

风险管理（Risk Management）是指如何在项目或者企业一个肯定有风险的环境里把风险减至最低的管理过程。风险管理是指通过对风险的认识、衡量和分析，选择最有效的方式，主动地、有目的地、有计划地处理风险，以最小成本争取获得最大安全保证的管理方法。

从系统开发的角度看，风险管理包括系统中的风险的位置，确定哪些风险必须消除，哪些风险可以暂时存在，以及如何降低这些留存风险发生的可能性和重要性。

风险主要由可能性和严重性两方面组成：

  • 严重性：如果风险发生，所需付出的代价
  • 可能性：风险发生的概率

管理风险就是要管理这两个方面。

3.2 风险模型

风险模型是风险管理的第一步：理解系统中已有的风险，识别、标记并对已知的风险排列优先级，最终形成一张包含了系统所有已知风险的当前状态的表格。这就是我们所说的风险模型。

建立风险模型的过程是识别风险的过程，在这个过程中我们需要识别出系统中已有的风险，并对其进行分析，标记出优先级、梳理当前状态和历史情况。

风险模型构建过程中需要考虑模型的作用范围，是公司级的，团队级的，项目组的，还是服务级的。

对于一个小公司，可以是公司级的，对于大型一些的公司，可以考虑团队或项目级的。

风险模型至少包括以下一些方面：

  • 严重性/可能性：高中低，先评估严重性，再评估可能性
  • 风险缓和计划：可以使用的或者正在使用的用来降低该风险严重性或者可能性的风险缓和措施。
  • 监控：对该风险的发生是否进行了监控，如果监控了说明监控的指标，如果没有监控，说明原因，以及达成监控目标的原因，最终所有的风险应该是要监控起来的。
  • 状态：活跃 / 已缓和 /  正在修复 / 已解决
  • 历史风险情况：该风险在历史上有没有发生过，什么时候，发生频率等
  • 风险缓和计划：当我们制定风险缓和计划的时候，需要从严重性最高的项开始，缓和风险不是为了消除，而是为了降低风险的严重性和可能性。并不是每一个风险都要制订风险缓和计划。
  • 风险预案：当风险发生的时候，我们可以采取的措施

除此之外，还包括一些常规的添加时间，ID，负责人之类的

3.3 识别风险

我们参照如上风险模型的项，通过头脑风暴等方式构建整个风险模型，在过程中可以考虑从如下的一些点中提取风险点：

  • 已知的故障
  • 有出现的告警
  • 用户支持的反馈
  • 可能存在的性能问题，或者一些慢 SQL 等
  • 服务间的强弱依赖
  • 一些功能的缺失
  • 服务单点
  • 内部和外部/离线和在线业务的相互影响
  • 服务容量的不足
  • 基建发布或扩容等发布操作会影响业务的情况
  • 线上配置/环境/网络等的变更
  • 安全问题
  • 系统或流程的问题，如没有文档，没有沉淀，只在某些人的脑袋里面
  • 一些已知的，明确的技术债务

基于上面的逻辑，我们梳理后可以得到一个风险列表，我们称之为风险模型。

3.4 风险缓和计划

风险模型中的风险缓和计划用来说明可以进行或者正在进行哪些风险缓和措施，来降低当前风险的严重性、可能性。这里我们不需要完全消除风险，只是降低风险发生的可能性和严重性。

常见的风险缓和计划，我们一些常见的降级策略属于风险缓和计划的主要部分，包括但不限于：

  • 前端降级：应对后端服务不可用或后端服务异常等风险；
  • 缓存降级：应对存储不可用或下游服务不可用等风险；
  • 主备切换：应对主存储不可用等风险；
  • 业务隔离：应对多业务接入时，单个业务引起的整体服务不可用的风险；
  • 应用限流：应对多业务接入时，单个业务引起的整体服务不可用的风险；
  • 整体限流：应对大流量突发的风险，保障部分用户可用；
  • 容量评估及提前扩容：应对大流量突发的风险，保障一定程度流量下的业务稳定性；
  • 全链路压测：应对整体链接容量不一致的风险，防止单点容量风险；
  • 线上问题及用户反馈清理：应对系统中小的风险引起的大风险，如一些系统 BUG，一些没有测出来的问题等等；
  • 线上告警及时处理：应对系统中小的风险引起的大风险，如一些系统 BUG;
  • 扩缩容演练：应对容量冲击时基建没有准备好的风险；
  • 定期压测及容量评估：应对系统演化过程中，代码变更，模块变更导致的容量变化；
  • 性能优化：应对系统中某些服务的性能问题导致的风险；

以上的一些策略只是缓和了部分风险，像容量的风险，BUG 的风险，不可用的风险不可能完全消除，只能缓和，以降低风险发生的可能性，或者降低风险发生时的严重性。

基于以上的一些思路，我们需要做一些专项和一些机制来保证风险可控。

但风险之所以为风险，是说明他还是有可能发生的，当发生时我们需要做什么呢，这就是我们接下来要准备的预案。

当风险发生时，我们计划如何来处理，这个计划是我们有预先设计的，是一个系统性的计划。

比如，当容量突发时，开启降级策略或者限流策略等等。

3.5 定期风险回顾，维护风险模型

风险模型是稳定性治理过程的抓手，通过不停的识别风险，消除风险，缓和风险，不断提高稳定性变好的可能，以最终达到稳定性的目标。

风险评估和应对规划是一个反复重复的过程，不停的迭代风险模型，识别出新的风险。

当风险模型构建完成后，我们需要定期逐个风险拉出来 review 一次，我们可以问我们自己如下的一些问题：

  • 与上次回顾相比，风险有更严重吗？可能性有更高吗？
  • 接下来会排专人来解决某些风险吗？是否应该安排？
  • 上次回顾安排的事项落实了，对应的风险情况如何，是否有更新到风险模型中？

问完问题，我们可能需要有一些实际的行动：

  • 评估是否有新的风险；
  • 删除旧的风险：如果风险已经解决了，可以归档；
  • 评估原有风险模型中的每一项风险，评估其严重性和可能性，如果有变动，对其进行更新；
  • 对于不同的优先级的风险区别对待。

以上的回顾操作我们建议以某个管理系统来承载，并且这个管理系统是带有通知等功能，以更好的将风险相关的信息周知出去，如 Jira 系统。

写在最后

记得当年「我是歌王」有一段汪涵救场的主持，从一个观众的角度看，真的牛逼，简直是教科书式，这算是一个超大的线上事故，但是这和我们的稳定性有什么关系呢，我们有如下的思考点：

  1. 为什么会有这个事故发生 – 问原因
  2. 在流程和机制上是否有改进的空间来规避 – 如何系统性的规避
  3. 这个事故有没有其它更平滑的处理方案，减少对用户的影响 – 如何减少影响
  4. 我们是否需要英雄 – 线上不应该有英雄

如同扁鹊的大哥一样：「长兄于病视神，未有形而除之，故名不出于家」

最后有一些原则可以指导我们稳定性的工作：

  1. 以用户为中心，不打扰，不影响
  2. 灰度，产品灰度，发布灰度，坚持住
  3. 防微杜渐，敬畏线上
  4. 快速发现，快速解决，减少对于用户的影响

重复一句：我们所做的一切都是以减少对客户的打扰为前提。

在我们所有的事项中并没有写与组织结构、人才梯队相关的内容，并不是这些不需要，恰恰相关，他们至关重要。下次有机会我们再聊。

最后，祝大家新年快乐~