在 基于Terraform在AWS ECS中构建Jenkins持续集成体系 一文中， Alliot 采用了 EFS 作为 Jenkins 容器的数据卷，直接挂载了 /var/jenkins_home 目录。
正如评论区提到的， 我们在使用 bursting 模式的 EFS 时，遇到了 IO 性能的问题， 虽然 master + slave 架构的 Jenkins 将构建任务分发到了 slave 节点，减少了 master 节点的压力，但是在启动构建任务时， master 节点依然会有大量的 IO 操作， 这个时候会导致 bursting 模式下的 EFS 瞬间打光 Credit 从而导致整个 master 挂掉。当然，我们可以使用 Provisoning 模式缓解性能问题，但其价格又非常贵，性价比不高。
好在从今年(2024)的一月开始， AWS ECS 的 Fargate 支持使用 EBS 卷作为 Volume 了。 目前官网的文档还比较分散，这里小记一些需要注意的点。
我们的部分后端服务正在经历容器化的改造， 由于历史包袱，现网的网关等设施无法一次性迁移到 k8s 集群中， 因此使用 Nginx proxy_pass 转发到 AWS ALB 这样一个曲线救国的临时方案。
但是在使用时，我们发现一段时间后 Nginx 出现了 504 的错误，检查后端服务均是正常的，而单独访问 ALB 也是正常响应的，因此便有了此文。
从2020年到2021年，我在亚马逊（AWS云）担任软件开发工程师（SDE）。有人说SDE代表”Someone Does Everything”（什么都做的人），这相当准确。在亚马逊，每位SDE软件工程师都负责从设计、编码到测试的所有工作，还需要定期轮值紧急响应任务。大多数亚马逊团队由6-8名工程师和一名软件开发经理（SDM）组成，遵循“两个披萨团队” （Two Pizza Team）的原则。
每位SDE软件工程师通常每6-7周需要轮值一次Oncall（紧急响应任务），持续一整周24/7待命。在此期间，你需要处理和解决业务上出错的问题（比如服务器宕机，原因可能：程序出错崩溃、硬盘空间不足、CPU温度过高等）。为此，你需要在手机上安装紧急响应软件（Pong），以接收与团队产品相关的警报。当警报响起时，你必须在15分钟内确认工单。如果没有及时确认，问题会逐级上报，甚至可能报告到CEO姐夫贝佐斯 Jeff Bezos，这可能会对你的绩效评估产生负面影响。
我听说有个软件工程师下班后和同事到酒吧里喝两杯，然后警报响了，他淡定的拿起笔记本就处理起来了。
亚马逊 Amazon
亚马逊的理念是你拥有自己的代码/You own your code。这意味着即使在半夜，警报响了，你也得爬起来解决问题。你的首要任务是恢复服务/Mitigation，其次是调查原因和解决。如果警报在凌晨3点响起，您可以临时重启服务器来解决问题，详细调查可以第二天起床后再进行。如果你在半夜被警报唤醒，第二天可以多休息，不用担心早晨的站会（敏捷开发每天都有例会）。
程序也需要Oncall就会促使他们尽可能的写出高质量的代码，避免BUG日后找麻烦。
这里顺便说一下，我在亚马逊S3的那个组，敏捷开发是2周一个短跑（Sprint），轮到oncall的工程师需要专注于Oncall DevOps，相当于是一个任务（多少点我忘记了），如果不太需要处理警报，则可以适当做一些其它开发任务。对我来说，压力最大的是在Oncall完的第二周，需要写报告，并在每周大会上给大家讲每个警报的原因和处理方案。
这个Oncall非常让人有压力，但它们有效地训练了软件工程师的DevOps技能。由于高灵敏度设置，新产品往往会生成更多警报。亚马逊以其99.99%的服务水平协议（SLA）而自豪，这要归功于SDE的紧急响应文化。
以下是我在2021年担任亚马逊SDE期间最后一次轮值时收到的警报示例。警报声可能非常刺耳，类似空袭警报，不过也有一些不那么刺耳甚至更愉快的铃声可供选择。当时这声音简直是恶梦。
我在Oncall那周，我媳妇都不愿意和我睡，因为大晚上的被警报吵醒是件很吓人并且让人很不爽的事情。当我离开亚马逊来到微软剑桥研究院后，立马压力就小很多，而且人也开心很多，朋友圈状态都比较频繁了。
其实，我感觉Oncall这事不讨好的一个很大原因是在英国Oncall是不额外给钱的，都属于本职工作的一部分。而据说在德国，Oncall是会有额外经济补偿的，在金钱的加持下，我感觉这事的体验感肯定天壤之别。
英文：The Experience of On-call (Paging) for Amazon Software Engineers
本文一共 991 个汉字, 你数一下对不对.
在 基于Terraform在AWS ECS中构建Jenkins持续集成体系 一文中， Alliot 采用了 EFS 作为 Jenkins 容器的数据卷，直接挂载了 /var/jenkins_home 目录。
正如评论区提到的， 我们在使用 bursting 模式的 EFS 时，遇到了 IO 性能的问题， 虽然 master + slave 架构的 Jenkins 将构建任务分发到了 slave 节点，减少了 master 节点的压力，但是在启动构建任务时， master 节点依然会有大量的 IO 操作， 这个时候会导致 bursting 模式下的 EFS 瞬间打光 Credit 从而导致整个 master 挂掉。当然，我们可以使用 Provisoning 模式缓解性能问题，但其价格又非常贵，性价比不高。
好在从今年(2024)的一月开始， AWS ECS 的 Fargate 支持使用 EBS 卷作为 Volume 了。 目前官网的文档还比较分散，这里小记一些需要注意的点。
我们的部分后端服务正在经历容器化的改造， 由于历史包袱，现网的网关等设施无法一次性迁移到 k8s 集群中， 因此使用 Nginx proxy_pass 转发到 AWS ALB 这样一个曲线救国的临时方案。
但是在使用时，我们发现一段时间后 Nginx 出现了 504 的错误，检查后端服务均是正常的，而单独访问 ALB 也是正常响应的，因此便有了此文。
这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务，成本降低90%》，副标题：“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”，有人把这篇文章在五一期间转到了reddit 和 hacker news 上，在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”，还是Amazon干的，这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。
今天上午有好几个朋友在微信里转了三篇文章给我，如下所示：
看看这些标题就知道这些文章要的是流量而不是好好写篇文章。看到第二篇，你还真当 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）帐户对 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）AWS 的 Serverless 也好， 微服务也好，单体也好，在合适的场景也都很香。这就跟汽车一样，跑车，货车，越野车各有各的场景，你用跑车拉货，还是用货车泡妞都不是一个很好的决定。
2）这篇文章中的这个例子中的业务太过简单了，本来就是一两个服务就可以干完的事。就是一个转码加分析的事，要分开的话，就两个微服务就好了（一个转码一个分析），做成流式的。如果不想分，合在一起也没问题了，这个粒度是微服务没毛病。微服务的划分有好些原则，我这里只罗列几个比较重要的原则：
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%的云计算成本）。目前可以降低成本的方式：
欢迎大家试用。
如何访问
注：这两个区完全独立，帐号不互通。因为网络的不可抗力，千万不要跨区使用。
产品演示
介绍文章
（全文完）
（转载本站文章请注明作者和出处 酷 壳 – CoolShell ，请勿用于任何商业用途）
登录
