这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务，成本降低90%》，副标题：“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”，有人把这篇文章在五一期间转到了reddit 和 hacker news 上，在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”，还是Amazon干的，这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。

今天上午有好几个朋友在微信里转了三篇文章给我，如下所示：

• 《微服务是不是个蠢主意？》
• 《单体回归？亚马逊放弃用于视频监控的微服务 》
• 《从微服务转为单体架构、成本降低 90%，亚马逊内部案例引发轰动》

看看这些标题就知道这些文章要的是流量而不是好好写篇文章。看到第二篇，你还真当 Prime Video 就是 Amazon 的全部么？然后，再看看这些文章后面的跟风评论，我觉得有 80%的人只看标题，而且是连原文都不看的。所以，我想我得写篇文章了……

原文解读

要认清这个问题首先是要认认真真读一读原文，Amazon Prime Video 技术团队的这篇文章并不难读，也没有太多的技术细节，但核心意思如下：

1）这个系统是一个监控系统，用于监控数据千条用户的点播视频流。主要是监控整个视频流运作的质量和效果（比如：视频损坏或是音频不同步等问题），这个监控主要是处理视频帧，所以，他们有一个微服务主要是用来把视频拆分成帧，并临时存在 S3 上，就是下图中的 Media Conversion 服务。

2）为了快速搭建系统，Prime Video团队使用了Serverless 架构，也就是著名的 AWS Lambda 和 AWS Step Functions。前置 Lambda 用来做用户请求的网关，Step Function 用来做监控（探测器），有问题后，就发 SNS 上，Step Function 从 S3 获取 Media Conversion 的数据，然后把运行结果再汇总给一个后置的 Lambda ，并存在 S3 上。

整个架构看上去非常简单 ，一点也不复杂，而且使用了 Serverless 的架构，一点服务器的影子都看不见。实话实说，这样的开发不香吗？我觉得很香啊，方便快捷，完全不理那些无聊的基础设施，直接把代码转成服务，然后用 AWS 的 Lamda + Step Function + SNS + S3 分分钟就搭出一个有模有样的监控系统了，哪里不好了？！

但是他们遇到了一个比较大的问题，就是 AWS Step Function 的伸缩问题，从文章中我看到了两个问题（注意前方高能）：

1. 需要很多很多的并发的 AWS Step Function ，于是达到了帐户的 hard limit。
2. AWS Step Function 按状态转换收费，所以，贵得受不了了。

注意，这里有两个关键点：1）帐户对 Step Function 有限制，2）Step Function 太贵了用不起。

然后，Prime Video 的团队开始解决问题，下面是解决的手段：

1） 把 Media Conversion  和 Step Function 全部写在一个程序里，Media Conversion 跟 Step Function 里的东西通过内存通信，不再走S3了。结果汇总到一个线程中，然后写到 S3.

2）把上面这个单体架构进行分布式部署，还是用之前的 AWS Lambda 来做入门调度。

EC2 的水平扩展没有限制，而且你想买多少 CPU/MEM 的机器由你说了算，而这些视频转码，监控分析的功能感觉就不复杂，本来就应该写在一起，这么做不更香吗？当然更香，比前面的 Serverless 的确更香，因为如下的几个原因：

1. 不再受 Step Function 的限制了，技术在自己手里，有更大的自由度。
2. 没有昂贵的 Step Function 云成本的确变得更低了，如果你把 Lambda 换成 Nginx 或 Spring Gateway 或是我司的 Easegress，你把 S3 换成 MinIO，你把 SNS 换成 Kafka，你的成本 还能再低。

独立思考

好了，原文解读完了，你有自己的独立思考了吗？下面是我的独立思考，供你参考：

1）AWS 的 Serverless 也好， 微服务也好，单体也好，在合适的场景也都很香。这就跟汽车一样，跑车，货车，越野车各有各的场景，你用跑车拉货，还是用货车泡妞都不是一个很好的决定。

2）这篇文章中的这个例子中的业务太过简单了，本来就是一两个服务就可以干完的事。就是一个转码加分析的事，要分开的话，就两个微服务就好了（一个转码一个分析），做成流式的。如果不想分，合在一起也没问题了，这个粒度是微服务没毛病。微服务的划分有好些原则，我这里只罗列几个比较重要的原则：

• 边界上下文。微服务的粒度不能大于领域驱动里的 Bounded Context（具体是什么 大家自行 Google），也就是一个业务域。
• 单一职责，高内聚，低耦合。把因为相同原因变化的合在一起（内聚），把不同原因变化的分开（解耦）
• 事务和一致性。对于两个重度依赖的功能，需要完成一个事务和要保证强一致性的，最好不要拆开，要放在一起。
• 跟组织架构匹配。把同一个团队的东西放在一起，不同团队的分开。

3）Prime Video 遇到的问题不是技术问题，而是 AWS  Step Function 处理能力不足，而且收费还很贵的问题。这个是 AWS 的产品问题，不是技术问题。或者说，这个是Prime Video滥用了Step Function的问题（本来这种大量的数据分析处理就不适合Step Function）。所以，大家不要用一个产品问题来得到微服务架构有问题的结论，这个没有因果关系。试问，如果 Step Funciton 可以无限扩展，性能也很好，而且白菜价，那么 Prime Video 团队还会有动力改成单体吗？他们不会反过来吹爆 Serverless 吗？

4）Prime Video 跟 AWS 是两个独立核算的公司，就像 Amazon 的电商和 AWS 一样，也是两个公司。Amazon 的电商和 AWS 对服务化或是微服务架构的理解和运维，我个人认为这个世界上再也找不到另外一家公司了，包括 Google 或 Microsoft。你有空可以看看本站以前的这篇文章《Steve Yegg对Amazon和Google平台的吐槽》你会了解的更多。

5）Prime Video 这个案例本质上是“下云”，下了 AWS Serverless 的云。云上的成本就是高，一个是费用问题，另一个是被锁定的问题。Prime Video 团队应该很庆幸这个监控系统并不复杂，重写起来也很快，所以，可以很快使用一个更传统的“服务化”+“云计算”的分布式架构，不然，就得像 DHH 那样咬牙下云——《Why We’re Leaving the Cloud》（他们的 SRE 的这篇博文 Our Cloud Spend in 2022说明了下云的困难和节约了多少成本）

后记

最后让我做个我自己的广告。我在过去几年的创业中，帮助了很多公司解决了这些 分布式，微服务，云原生以及云计算成本的问题，如果你也有类似问题。欢迎，跟我联系：haoel@hotmail.com

另外，我们今年发布了一个平台 MegaEase Cloud， 就是想让用户在不失去云计算体验的同时，通过自建高可用基础架构的方式来获得更低的成本（至少降 50%的云计算成本）。目前可以降低成本的方式：

1. 基础软件：通过开源软件自建，
2. 内容分发：MinIO + Cloudflare 的免费 CDN，
3. 马上准备发布的直接与底层IDC合作的廉价GPU计算资源…

欢迎大家试用。

如何访问

• 中国区:   https://cloud.megaease.cn 
• 国际区：https://cloud.megaease.com

注：这两个区完全独立，帐号不互通。因为网络的不可抗力，千万不要跨区使用。

产品演示

• https://www.bilibili.com/video/BV17v4y1R7mA/

介绍文章

• 欢迎使用 MegaEase Cloud
• 2023 年 03 月重大更新

 

（全文完）

The post 是微服务架构不香还是云不香？ first appeared on 酷 壳 - CoolShell.

写一篇与技术无关的文章，供大家参考。我住北京朝阳，从上周三开始我家一家三口陆续发烧生病，自测抗原后，都是阳性。好消息是，这个奥密克戎跟一般的病毒性感冒差不多，没什么可怕的，不过，整个过程除了发病之外还有一些别的因为感染带出来的事，大家也需要知晓，以准备好，以免造成生活的不便，更好的照顾好自己和家人。

整个过程

我先说一下整个过程（我会不断更新这个过程，直到转阴）。说明一下，我孩子老婆都打过三针国产疫苗，孩子是科兴，老婆是北京生物，我完全没有打。

先是我家孩子（12 岁）。上周三（12 月 7 日），孩子早上起来就说头疼，一测体温，38 度 5，就停止上网课，老实休息了，我们并没给孩子吃什么药，到了晚上，孩子的体温到了 39.4，嗓子疼，我老婆用酒精给孩子物理降温（注：事实上最好别用酒精，因为会被皮肤吸收导致副作用），成功降到了 38.2 左右。周四（12 月 8 日），孩子的体温在 38.2 一天，我老婆给孩子吃了莲花清瘟，被我制止了，本来想上退烧药的，但是我想体温也不算高，能不吃就不吃，于是就让孩子冲了个复方感冒冲剂（其实里面含对乙酰氨基酚，后面会说）。周五（12 月 9 日），孩子不停地出汗，到下午体温正常了，然后咳嗽，鼻涕就来了，感冒症状来了，但精神不好，体虚无力。周末休息两天就基本没事了，也转阴了。

接下来就到我了。

周五那天感觉嗓子有点异样，我没怎么在意，周六（12 月 10）就开始发烧了，傍晚 18 点左右，我是手脚冰冷，还有点打冷颤，头晕，嗓子干燥，我就钻被子里了，在半睡不睡的状态下到了 20 点左右，我浑身发烫，我老婆过来给我一量体温，39.8，说要不要也抹点酒精？我想，北京这个季节，物理降温不就上阳台上站一会就好了吗？当然，我就是把窗开了个口，把室温降到 20 度左右，然后，短袖短裤呆了一会就感到清醒了一些。这个时候，我觉得再来碗热汤就好了，我喝不习惯生姜红糖水，又腥又甜，我就自己整了一小锅西红柿蛋花汤，为了让我更能出汗，并适合我的重口味，我又加了点辣椒，一小锅热汤下肚，汗出的不亦乐乎，体温降低到38.4度，我觉的不用再吃药了，当然，嗓子也疼了。但是我舒服了很多，最后还看了下摩洛哥是怎么把C罗送回家的比赛。

周日（12 月 11）是我最难受的一天，全天体温在 38.2左右，从早上就没有精神，吃完早点后，从 10 点一直睡到下午 15 点（因为嗓子疼，所以睡的也不安宁，各种难受）， 这天我一会儿就出次汗，但是体温降不下来，始终在 38.2，然后我在犹豫是不是吃布洛芬，但是我感觉体温也不是很高，布洛芬这种药能不吃不不吃。然后，睡前喝了一袋感冒冲剂。周日这天，我婆也发烧，38.5，她全身疼痛，包括嗓子。这一天，我们在家啥也干不了，全家都在床上躲着，只有孩子还能动，所以，有些事只能让孩子去干了，我们也只点外卖了。

周一（12 月 12 日）我早上起来，38.5，开完周会后，看很多人说泰诺有用，然后翻了一下家，居然没找到，算，还是冲两包感冒冲剂得了（后来才知道，中成药里也都是掺了对乙酰氨基酚，看来中医对自己都没什么信心），于是整个下午就在出汗了，我一整天都没有什么食欲，到了下午 17 点左右，体温正常了 36.7，但是晚上又到了 37 度，开始咳痰，轻微流鼻涕，不过感觉没什么事了。而我老婆的烧居然退了，她说她应该好了。

周二（12 月 13 日）我早上起床后， 体温还是在 37.2 度，我的嗓子干燥微疼，头也不疼就是头晕，所以，今天睡了两次，一次是中午12 点半到下午 14点半，一次是 16：40 到 19:10，两次都出汗了，而且第二觉睡地太爽了，感觉是这两天睡过最高质量高的觉，而且嗓子不干了也好了，体温正常了 36.8，但是感冒症状出来了，接下来几天休息一下应该就好了。我孩子应该感冒也没有精神，所以一天来也是醒醒睡睡。而我老婆又开始发烧了，还带这样的，跳跃性发烧…… 更不好的是她嗓子已经疼到说不出话，也咽不下东西了，今天她也是床上躺了一天……

周三（12月14日）我今天已经不发烧了，就是频率不高的咳嗽，轻微鼻塞，不过，还是要休息，喝水。我老婆体温还是低烧中，嗓子疼痛好了些，感觉正在恢复中……

整个过程，对我和我孩子来说，不难受，感觉就是发3天烧睡3天，再休息 3 天的样子，嗓子干燥微疼，比以前的病毒性感冒好多了，以前的病毒性感冒导致的嗓子疼我是连咽口水都咽不下去。但是对于我老婆就不一样了，她先是浑身疼痛，嗓子干燥，到现在嗓子疼如刀割，说不出话。这个事可能也因人而异。

继续更新，自我阳性以来半个月了，从 12 月 14 日退烧后，我就一直处在感冒和低频咳嗽中，直到12 月 27 日才发现不咳嗽也不感冒了，但是说话还是有一点鼻音，估计还要 5-7 天就可以完全恢复了。

注意事项

能物理降温就不要吃药来降（应该避免使用酒精擦拭，因为有副作用，用水或冰就可以了），降到 38.5 以下，就可以自己抗了。如果物理降温不奏效，就要吃布洛芬和泰诺(林)，这两种药非常有帮助，但是你应该在药店里买不到了，所以，你可以买中成药或复方药，反正里面的中药没有用，而几乎所有的中成药里都被加入了“对乙酰氨基酚”，算是“间接”或“复方”泰诺(林)了。但是，不要多服，不然，药量叠加，会导致你肝肾中毒。参看《这些所谓“中成药”，关键原料是对乙酰氨基酚，服用小心叠加过量》

下面文字节选自“默沙东诊疗手册”

最有效和最广泛使用的退热药为对乙酰氨基酚和非甾体抗炎药 (NSAID)，如阿司匹林、布洛芬和萘普生。

通常，人们可能采取以下方式之一：

• 每6小时650毫克对乙酰氨基酚（1天内不超过4000毫克）

• 每6小时200到400毫克布洛芬

因为许多非处方感冒药或流感制剂含有对乙酰氨基酚，人们一定要注意不要在同一时间服用对乙酰氨基酚和一种或多种这些制剂。

只有当温度达到106°F (41.1°C)左右或更高时，才需要采取其它降温措施（如用温水喷雾和降温毯降温）。避免使用酒精擦拭，因为酒精可被皮肤吸收，可能产生有害效果。

有血液感染或生命体征异常（例如，血压低、脉搏和呼吸速度加快）的人需入院。

另外，一定要多喝水，热水最好。多喝水的原因是：1）布洛芬、对乙酰氨基酚（扑热息痛）等退烧药会让人加速出汗，会导致脱水。2）布洛芬等退烧药主要在肝脏代谢，60%~90%经肾脏随尿排出。多喝水，可加速药物排出体外，减少退烧药对肝肾的损伤。3）排汗和排尿都会帮身体带走一些热量。

具体喝多少水因人而异，一般在2.5升到4升间，主要看你上厕所的频率。我因为前三天都在出汗，所以怎么喝水都不怎么上厕所，这两天我大概一天喝4升左右。总之，发烧吃退烧药更要多喝水。

另外，如果全家都病倒了，那生活就有点不方便了，所以，你得做好一些准备：

1）事先订好桶装水，18L 的那种，让人可以给家里送水，发烧期间用水很快的。

2）生活上的事要做好全家病倒的准备，做饭只能整方便的做的或是速食的了，家里存点牛奶，面包，麦片，火腿肠，水果什么的，保证营养。再不行就点外卖，我家已经点了三天的外卖。还让孩子当个配送员跑腿到菜市场和超市开着视频买东西……

3）还是要提前备药，我是准备用药的时候，发现家里只找到了布洛芬和感冒冲剂，因为我有高血脂，我还要吃瑞舒伐他汀钙片，结果发现我周边 5 公里的药店基本全都休业了，估计店员都阳了。

4）有老人的，要照顾好。有呼吸困难的，一定要送急诊。

根据知乎上的这个通过搜索引擎的测算，第一波的结束大约会在明年春节前结束。最后祝大家好运。

（全文完）

The post 感染新冠的经历 first appeared on 酷 壳 - CoolShell.

这两天跟 Cali 和 Rather 做了一个线上的 Podcast – Ep.5 一起聊聊团队协同。主要是从 IM 工具扩展开来聊了一下团队的协同和相应的工具，但是聊天不是深度思考，有一些东西我没有讲透讲好，所以，我需要把我更多更完整更结构化的想法形成文字。（注：聊天聊地比较详细，本文只是想表达我的主要想法）

国内外的企业 IM 的本质差别

国内企业级在线交流工具主要有：企业微信、钉钉、飞书，国外的则是：Slack、Discord这两大IM工具，你会发现，他们有很多不一样的东西，其中有两个最大的不同，一个是企业管理，一个是企业文化。

企业管理

Slack/Discrod 主要是通过建 Channel ，而国内的IM则主要是拉群。你可能会说，这不是一样的吗？其实是不一样的，很明显，Channel 的属性是相对持久的，而群的属性则是临时的，前者是可以是部门，可以是团队，可以是项目，可以是产品，可以是某种长期存在的职能（如：技术分享），而拉群则是相对来说临时起意的，有时候，同样的人群能被重复地拉出好几次，因为之前临时起意的事做完了，所以群就被人所遗忘了，后面再有事就再来。很明显，Channel 这种方式明显是有管理的属性的，而拉群则是没有管理的。

所以，在国内这种作坊式，野蛮粗放式的管理风格下，他们需要的就是想起一出是一出的 IM 工具，所以，拉群就是他们的工作习惯，因为没有科学的管理，所以没有章法，所以，他们不需要把工作内的信息结构化的工具。而国外则不然，国外的管理是精细化的，国外的公司还在重度使用 Email 的通讯方式，而 Email 是天生会给一个主题时行归类，而且 Email 天生不是碎片信息，所以，国外的 IM 需要跟 Email 竞争，因为像 Email 那样给邮件分类，把信息聚合在一个主题下的方式就能在 IM 上找到相关的影子。Channel 就是一个信息分类，相当于邮件分类，Slack 的 回复区和 Discord 的子区就像是把同一个主题信息时行聚合的功能。这明显是懂管理的人做的，而国内的拉群一看就是不懂管理的人干的，或者说是就是满足这些不懂管理的人的需求的。

企业文化

团队协作和团队工作最大的基石是信任，如果有了信任，没有工具都会很爽，如果没有信任，什么工具都没用。信任是一种企业文化，这种文化不仅包括同级间的，还包括上下级间的。但是，因为国内的管理跟不上，所以，就导致了各种不信任的文化，而需要在这里不信任的文化中进行协同工作，国内的 IM 软件就会开发出如下在国外的 IM 中完全没有的功能：

• 监控员工。获取员工的工作时间以及工作位置。
• 有详细的已读标注。这样会给对方要回复的压力。
•  发出的信息不能修改，不能删除，非常有限地可撤回。

而国外的 IM 则是，发出的信息可以修改/删除，没有已读标准，也不会监控员工。这种时候，我总是会对工作在这种不信任文化中人感到可怜……如果大家需要靠逼迫的方式把对方拉来跟我一起协作，我们还工作个什么劲啊。

小结

所以，我们可以看到，畸形的企业管理和企业文化下，就会导致畸形的协同工具。最令人感到悲哀的是，有好多同学还觉得国内的钉钉非常之好，殊不知，你之所以感觉好用，是因为你所在的环境是如此的不堪。你看，人到了不同的环境就会有不同的认识，所以，找一个好一些的环境对一个人的成长有多重要。

给一些新入行的人的建议就是，一个环境对一个人的认知会有非常大的影响，找一个好的环境是非常重要，如果不知道什么 环境是好的，那就先从不使用钉钉为工作协同软件的公司开始吧……

什么是好的协同工具

我们从上面可以得到，协同的前提条件是你需要有一个基于信任的企业文化，还需要有有结构化思维的科学的管理思维。没有这两个东西，给你的团队再多的工具都不可能有真正好有协同的，大家就是装模作样罢了。

假设我们的管理和文化都没有问题，那下面我们来谈谈协同工具的事。

我个人觉得 IM 这种工具包括会议都不是一种好的协同工具，因为这些工具都无法把信息做到真正的结构化和准确化，用 IM 或是开会上的信息大多都是碎片化严重，而且没有经过深度思考或是准备的，基本都是即兴出来的东西，不靠谱的概率非常大。

找人交流和开会不是有个话题就好的，还需要一个可以讨论的“议案”。在 Amazon 里开会，会前，组织方会把要讨论的方案打印出来给大家看，这个方案是深思过的，是验证过的，是有数据和证据或是引用支撑的，会议开始后，10 -15分钟是没有人说话的，大家都在看文档，然后就开始直接讨论或发表意见，支持还是不支持，还是有条件支持……会议效率就会很高。

但是这个议案其实是可以由大家一起来完成的，所以，连打印或是开会都不需要。试想一下，使用像 Google Doc 这样的协同文档工具，把大家拉到同一个文档里直接创作，不香吗？我在前段时间，在公网上组织大家来帮我完成一个《非常时期的囤货手册》，这篇文章的形成有数百个网友的加持，而我就是在做一个主编的工作，这种工作是 IM 工具无法完成的事。与之类似的协同工具还有大家一起写代码的 Github，大家一起做设计的 Figma……这样创作类的协同工具非常多。另外，好多这些工具都能实时展示别人的创作过程，这个简直是太爽了，你可以通过观看他人创作过程，学习到很多他人的思路和想法，这个在没有协同工具的时代是很难想像的。

好的协同工具是可以互相促进互相激励的，就像一个足球队一样，当你看到你的队友在勇敢地争抢，拼命地奔跑，你也会被感染到的。

所以，好的协同就是能够跟一帮志同道合，有共同目标，有想法，有能力的人一起做个什么事。所以，在我心中我最喜欢的协同工具从来都是创作类的，不是管理类的，更不是聊天类的。管理和聊天的协同软件会让你产生一种有产出的假象，但其实不同，这种工具无论做的有多好，都是支持性的工具，不是产出类的工具，不会提升生产力的。

另外，在创作类的协同工具上如果有一些智能小帮手，如：Github 发布的 Copilot。那简直是让人爽翻天了，所以，真正能提升生产力的工具都是在内容上帮得到你的。

结束语

我其实并不喜欢今天所有的 IM 工具，因为我觉得信息不是结构化的，信息是有因果关系和上下文的，是结构化的，是多维度的，不是今天这种线性的方式，我们想像一下“脑图”或是知识图，或是 wikipedia 的网关的关联，我们可能就能想像得到一个更好的 IM 应该是什么 样的……

协同工作的想像空间实在是太大了，我觉得所有的桌面端的软件都会被协作版的重写，虽然，这种协作软件需要有网络的加持，但是协作软件的魅力和诱惑力实在的太大了，让人无法不从……

未来的企业，那些管理类的工具一定会被边缘化的，聊天类的会被打成一个通知中心，而创作类的会大放异彩，让大家直接在要干的事上进行沟通、交互和分享。

（全文完）

The post 聊聊团队协同和协同工具 first appeared on 酷 壳 - CoolShell.

分享信息并不难，大多数人都能做到，就算是不善言谈性格内向的技术人员，通过博客或社交媒体，或是不正式的交流，他们都能或多或少的做到。但是如果你想要做一个有质量有高度的分享，这个就难了，所谓的有质量和有高度，我心里面的定义有两点：1）分享内容的保鲜期是很长的，2）会被大范围的传递。我们团队内每周都在做技术分享，虽然分享的主题都很有价值，但是分享的质量参差不齐，所以，想写下这篇文章 。供大家参考。

首先，我们先扪心自问一下，我们自己觉得读到的好的技术文章是什么？我不知道大家的是什么，我个人认为的好的文章是下面这样的：

• 把复杂的问题讲解的很简单也很清楚。比如我高中时期读到这本1978年出版的《从一到无穷大》，用各种简单通俗通懂的话把各种复杂的科学知识讲的清清楚楚。还有看过的几本很好的书，有一本是《Windows程序设计》，从一个hello world的程序开始一步一步教你Windows下的原生态编程。
• 有各种各样的推导和方案的比较，让你知其然知其所以然。有了不同方案的比较，才可能让人有全面的认识。这个方面的经典作著是《Effective C++》。
• 原理、为什么、思路、方法论会让人一通百通。这里面最经典的恐怕就是《十万个为什么》了，在计算机方面也有几本经典书，有《Unix编程艺术》、《设计模式》、《深入理解计算机系统》等书，以及《The C10K Problem》等很多技术论文。

其实，从教科书，到专业书，再到论文，都有上面这些不错的特质。

所以，如果你想做一个好的技术分享的话，下面是我总结出来的方法，供你参考。

• 先描述好一个问题。这样能够听众带入进来，如果这个问题是他们感同身受的，那是最好了。千万不要一上来就说What，或是直接冲进答案里。这样的分享是在灌输和填鸭。把Why说清楚。没有Why，直接谈What的技术分享，通常来说价值不大。
• How比What重要。在讲How的时候，也就是如何解这个问题。
  • 先要把问题模型说清楚，有了问题模型这个框框后，方案才有意义。
  • 然后要有不同技术的比较。有了比较后，听众才会更相信你。
  • 直接上What的技术细节，其实没有太大意义。
• 一定要有Best Practice或方法论总结，否则上不了档次的。也就是分享中大家可以得到的重要收获。

说明了这个模型就是：问题 –> 方案 –> 总结。这其中是有一定的心理学模型的，具体表现如下：

• 用问题来吸引受众，带着受众来一起思考
• 用问题模型来框住受众的思考范围，让受众聚焦
• 给出几种不同的解决方案，比较他们的优缺点，让受众有一种解决问题的参与感。
• 最后，给出最佳实践，方法论或套路，因为有了前三步的铺垫，受众欣然接受。
• 整个过程会让受众有强烈的成长感和收获感。

这里有几个示例，也是我在我司 MegaEase 内部的技术分享，供你参考（我个人的YouTube频道）

技术分享：Prometheus是怎么存储数据的（Youtube）

技术分享：Distributed Lock Manager（Youtube）

下面是我写在我们公司内的Knowledge Sharing中的Best Practice，供参考

Sharing Guideline

Please follow the following sharing protocols

Understand Sharing

• Sharing is the hard way to learn knowledge. The presenter gains the biggest advantages. not audience. 分享是学习知识的最难的方式。分享者获得的好处最最多的，而不是观众。
• Sharing can open the knowledge door for the audience, but you have to walk to knowledge by yourself. 分享可以为听众打开知识的大门，但你能不能获得知识还要靠你自己。

Best Practices

To perform a great sharing, please follow the below practices.

• Do not share a big topic, a small topic is better. A big topic could make the audience lose focus. Remember, Less is More!
• Sharing time less than 60 mins is the best.
• English language for slides is preferred.
• While prepare the sharing contents, it’s better to discuss with the senior people to help you to see the whole picture, understand the good side and bad side, know what you don’t know … etc.
• Strong Recommend Materials Outlines
  • What’s the Problem?
  • How to Solve the Problem?
  • The Best Solution or Practice.
  • The Mechanism, Key Techniques, and Source Code
  • Pros/Cons
  • References (Further reading)

For example, if you want to sharing a topic about Docker. the following outlines would be good one:

• What’s the major problems need to solve. (Provision, Environment, Isolation etc.)
• The Alternative solutions. (Puppet/Chef/Ansible, VM, LXC etc.)
• The Best Solution – Docker. Why?
• Docker’s key techniques – image, cgroup, union fs, namespace…
• Docker’s Pros/Cons
• Further reading list.

（全文完）

The post 如何做一个有质量的技术分享 first appeared on 酷 壳 - CoolShell.