理解系统设计中的可用性百分比: 计算系统的停机时间(Availability)

2024年11月12日 04:50

aws-four-nines-sla 理解系统设计中的可用性百分比: 计算系统的停机时间(Availability) 学习笔记程序员系统设计计算机面试

亚马逊云AWS的SLA是4个9也就是99.99%在线时间uptime

在系统设计面试中，可用性百分比是软件工程师应该熟悉的基本知识。

在系统可靠性领域（System Availability），99.9% 或 99.99% 之类的可用性百分比是关键的基准。但是这些数字究竟意味着什么？它们又如何转化为实际停机时间（Downtime）？以下介绍了如何计算与不同可用性水平相关的停机时间，并使用示例来说明 99.9%、99.99% 和其他可用性目标所带来的预期。

什么是可用性百分比？

可用性百分比表示系统在给定时间段（通常是一年、一月或一天）内预计正常运行的时间比例。例如，99.9% 的可用性意味着系统在指定期间内可以停机 0.1% 的时间。

可用性百分比和停机时间

以下是根据不同时间段的可用性百分比计算停机时间的方法：

确定总时间周期：选择参考周期：
- 年：365 天，或 31,536,000 秒（365 天 × 24 小时 × 60 分钟 × 60 秒）
- 月：30 天，或 2,592,000 秒
- 日：24 小时，或 86,400 秒
计算允许的停机时间：使用公式：

停机时间 = 总时间周期 × (1 – 可用性百分比)

示例：99.9% 可用性的停机时间

99.9% 可用性的年度停机时间

一年中的总秒数：31,536,000
可用性：99.9% = 0.999
停机时间 = 31,536,000 × (1 – 0.999) = 31,536 秒
转换为小时和分钟：31,536 秒约为 8 小时 45 分钟

99.9% 可用性的月度停机时间

一个月中的总秒数：2,592,000
停机时间 = 2,592,000 × (1 – 0.999) = 2,592 秒
转换为分钟：2,592 秒约为 43.2 分钟

99.9% 可用性的每日停机时间

一天中的总秒数：86,400
停机时间 = 86,400 × (1 – 0.999) = 86.4 秒
转换为分钟：86.4 秒约为 1.44 分钟

更高可用性水平的停机时间

对于具有更高可用性目标的系统，如 99.99% 或 99.999%，允许的停机时间会变得更短。以下是总结不同可用性水平停机时间的表格：

可用性	年度停机时间	月度停机时间	每日停机时间
99.9%（三个 9）	约 8 小时 45 分钟	约 43.2 分钟	约 1.44 分钟
99.99%（四个 9）	约 52.6 分钟	约 4.4 分钟	约 8.6 秒
99.999%（五个 9）	约 5.3 分钟	约 26 秒	约 0.86 秒
99.9999%（六个 9）	约 31.5 秒	约 2.6 秒	约 86 毫秒

高可用性的重要性

具有高可用性目标的系统对于那些停机会直接影响收入、客户满意度或安全的行业至关重要。实现这些目标需要精心设计，包括负载均衡、冗余、故障转移机制，有时还需要资源的地理分布。

总结

可用性百分比提供了表达系统可靠性的一种方便方式，但将其转换为停机时间则可以更清楚地看到面临的风险。使用这些计算来设置现实的可用性目标，并相应地准备您的基础设施。

英文：Understanding Availability Percentages: Calculating Downtime for Your Systems

本文一共 768 个汉字, 你数一下对不对.

理解系统设计中的可用性百分比: 计算系统的停机时间(Availability). (AMP 移动加速版本)

赞赏我的几个理由.

¥ 打赏支持

扫描二维码，分享本文到微信朋友圈

75a5a60b9cac61e5c8c71a96e17f2d9c 理解系统设计中的可用性百分比: 计算系统的停机时间(Availability) 学习笔记程序员系统设计计算机面试

The post 理解系统设计中的可用性百分比: 计算系统的停机时间(Availability) first appeared on 小赖子的英国生活和资讯.

三次冲击谷歌软件工程师: 我的面试起伏录 (谷歌面试是不是一生只有三次机会?)

小赖子的英国生活和资讯

JustYY.com 小赖子的英国生活和资讯

2024年10月29日 21:53

Google（谷歌）是全球知名的互联网巨头之一，几年前被认为是养老终级大厂，福利优厚，压力相对较小。在英国伦敦，Google设有一个主要从事开发和研究的办公室。

第一次面试 2016年

我在2016年首次面试Google。第一轮是电话面试，由一位在瑞士的工程师主导，通过电话交流并在Google Doc上同步编写代码。由于当时技术水平有限，我用C++完成了那道消息打印的题目，核心是使用队列和哈希表来解决问题，写得很磕磕巴巴。

当时对软件工程师的级别没有特别概念，推测自己面的是SWE L4/L5的级别，因为当时也就工作了5年多。

我查了一下邮件，2013年11月份的时候谷歌猎头联系我问我要不要试试？我说我当时没拿到英国永居，不想冒险，虽然他说到谷歌可以办工签，我当时还是没有选择去面试，现在想起来实在不可思议，后来2014年/2015年的时候同一个猎头还每隔6个月就check-in一次，最后面是在2016年4月份的时候才开始第一次的。

hello-from-google-email-3-years 三次冲击谷歌软件工程师: 我的面试起伏录 (谷歌面试是不是一生只有三次机会?) 程序员软件工程面试

这个谷歌猎头很敬业，2014年联系我，最后跟踪了三年让我参加第一轮面试。

我要是当时聪明一些，努力刷题一些，搞不好当时进谷歌，现在也工作将近十年了，拿着谷歌股票到现在，也不至于现在混个高不成低不就的。

第二次面试 2020年

第二次面试是2020年11月份，第零轮其实应该算是Google的猎头问的一些选择题，比如C++里的哈希表/map如果访问一个不存在的键会发生什么？Google的软件工程师包括SRE站点可靠工程师在面试的时候都可以选两种路径，一个是数据结构和算法（编程），另一个是运维/DevOps偏LINUX知识的。我都选前者，毕竟这个我感觉只要短期刷题就好了，相反后者需要多年工作实战的积累。

通过了猎头的小测试，我进入了第一轮，是道编程题，但是并不是那种力扣上可以见到的，这一轮45分钟，给得是一个比较有意思的游戏，比如迷宫生成算法。面试的时候需要你主导整个过程，包括澄清问题，构思，写代码，分析复杂度等等，每一步都需要你Think Aloud。虽然这一轮我犯了些错误，但是给得反馈总题还不错，面试官说他觉得我应该进入下一轮。

到了终面，安排在了同一天，上午2轮，下午3轮，我记得3轮编程/Coding，一轮系统设计，一轮Culture Fit/Behavior/行为模式。除了系统设计是1小时，其它的4轮都是45分钟，谷歌的Coding面试45分钟都是解决1题即可，题目并不是力扣上的，题目范围/scope较大，偏难。一般来说coding完还会有一些Follow-up的问题，比如怎么优化算法。这个和Meta/Facebook的Coding面试不同，Meta百分百喜欢出力扣上原题，40分钟内需要解决2题力扣原题（留5分钟问问题），这个可以通过力扣按公司归类最近3/6个月的试题准备即可。

系统设计我记得是设计一个类似AWS S3的文件存储，也不知道是不是看我当时在AWS S3工作。很可惜，最后面这一轮不过关，当时我面的是L5（Senior），软件工程师级别越往上走，对系统设计的能力则要求越高（设计可扩展/分布式/高性能的系统）。

Unfortunately Google doesn’t disclose specific feedback per interview session so in this case I can’t share more context. I wish I had more to share with you! Also, we don’t use the scoring system from 1-4 anymore, each person puts in full context, notes, and recommendations and then HC reviews for an overall consensus decision.

不幸的是，Google 不会披露每个面试环节的具体反馈，因此在这种情况下我无法分享更多背景信息。我希望我能与您分享更多！此外，我们不再使用 1-4 的评分系统，每个人都会提供完整的背景信息、注释和建议，然后由 HC 进行审查以做出总体共识决定。

一般大厂来说，不太会降级别给Offer，也就是说，如果面的是L5职位，但是能力可能只到L4，一般来说是不会给Offer的，但也不排除个别情况下，据说Meta就有面试E5给E4的情况。

级别是在面试过程中根据您的个人背景确定的，包括简历经验、面试表现等多种因素，以及与 SWE/SRE 的契合程度。

Unfortunately we reviewed for overall technical depth slotted against our teams and right now the decision is not to proceed.

不幸的是，我们审查了我们队伍的整体技术深度，现在的决定是不继续。

这次面试的职位是SRE站点可靠工程师。

我的面试谷哥GOOGLE伦敦SRE的经验和教训

第三次面试 2024年

其实去年2023年，也申请了谷歌伦敦Google Research的位置，当时和猎头简单聊过之后，就没下文了，猎头说会把我的简历给招聘经理，不过等了好几周，最后面很抱歉的说已经招了别人了。

Apologies for the radio silence on this one, we have had radio silence from the hiring manager on this role. They have unfortunately decided to prioritise other hiring areas in the team so we won’t be able to move forward at this stage.

However, if we have any other roles in the future I will make sure to keep you in mind.

抱歉，我们没有得到任何回复，我们一直没有收到招聘经理关于这个职位的任何回复。不幸的是，他们决定优先考虑团队中的其他招聘领域，因此我们目前无法继续推进。

但是，如果我们将来有其他职位，我一定会记住你的。

2021年/2022年我记得也投过，不过都没有下文（简历被拒），有一年直接申请Google瑞士，因为听说那边的工资高，和美国一样高，所以想试了试，第二天直接收到了拒信，还是谷歌瑞士的工程师直接发的邮件。

今年就随手申请了一下，也不知道是不是招聘市场回暖，简历同时过了Meta和Google的第一轮筛选。上一次2020年也是，同一时间面试Google和Meta，两个公司的面试都进入了最后一轮（Final Onsite）。

今年和Google猎头聊了聊，她并没有给小测试，就是了解了情况，然后让我选是以算法为主还是运维/DevOps为主，我今年面试的是SRE站点可靠工程师，和第二次一样。

第一轮面试也是一轮设计一个简化版的游戏，面试了45分钟，最后面拖了三分钟 Follow-up问题，也就是把这游戏 Scale Up，如果很多很多人玩，单机内存不够怎么办？

google-interview-first-round-coding-ring 三次冲击谷歌软件工程师: 我的面试起伏录 (谷歌面试是不是一生只有三次机会?) 程序员软件工程面试

今年第一轮谷歌面试在家里中午午休的时候进行的，45分钟。这个是当时我房间的Ring拍摄记录的。

我最开始的暴力解法写得很6，犯了两个小错误，并不是Bug Free，不过面试官指出后我立马意识到并改正了，后来优化需要用到二分搜索+前缀和/Prefix Sum，面试官很满意说他没想到这种方法。

再后来的优化用到了线段树，但由于时间限制，并不需要去实现，但需要讲明白算法原理。我脑子里想着另一种实现二叉索引树Binary Index Tree，但是不记得实现原理了，结果在那里纠结浪费了一些时间。

最后面给出的回馈就是最后面的Follow-up回答得不是很好。不过并没有立刻拒我，我猜是我过了Bar，但是并不是表现最好的那一个。一般一个职位一个坑，如果接到100份简历，那么只会邀请6-8个来进行第一轮面试，然后淘汰掉一半，最后面邀请3-4个来进行终面。

当时猎头给我打电话，说了反馈，然后就说暂时把我的申请on-hold了。

又过了两周，猎头给我回复：

I hope you’re keeping well, I just wanted to update you that we have now closed our London role. If we get another one through we will definitely be in touch! Thank you so much for everything you invested in our interviews, I know you put in a lot, on top of everything else and elsewhere too – and I know it takes a lot, so really do appreciate it, and I really hope we can keep in touch and work together again in the not so distant future! Take care and thank you again for everything you invested in our process, I really enjoyed working with you and getting to know you.

I wish you every strength, take care XXX!

希望你一切安好，我只是想告诉你，我们现在已经结束了伦敦的职位。如果我们又有新职位，我们一定会保持联系！非常感谢你为我们的面试所做的一切，我知道你付出了很多，除了其他一切之外，也付出了很多——我知道这需要很多，所以真的很感激，我真的希望我们能保持联系，在不久的将来再次合作！保重，再次感谢你为我们的过程所做的一切，我真的很高兴和你一起工作，认识你。

祝你一切顺利，保重 XXX！

我回了（不知道可不可以再投其它职位）：

Could I apply to other roles if there are any suitable in the meantime? Or is it better to just wait?

如果在此期间有其他合适的职位，我可以申请吗？还是最好等待？

更新：Google猎头隔了几天又回了：

I hope you’re keeping well! Thank you for your patience, we should have some roles coming live in London so I’ll catch up with you super soon! Good news!

希望你一切安好！谢谢你的耐心，我们应该会在伦敦有一些HC职位，所以我很快就会再次联系你！好消息！

每年都面试一下，才能知道自己几斤几两。

谷歌面试是不是一生只有三次机会？

谷歌的面试通常没有严格的次数限制，理论上并不是“一生只有三次机会”。不过，谷歌对多次申请有一定的冷却期政策，这意味着在未通过面试后，申请者需要等待一段时间才能再次申请。

通常的冷却期为6到12个月，但这时间会因具体情况和职位类型有所不同。如果之前的面试表现较好，甚至可以更早重新申请。此外，间隔期越长，对候选人的成长和进步的期望也会更高，因此再次面试时需要准备得更充分。

英文：Three Attempts at Google: My Software Engineer Interview Journey (Is There Only Three Chances in a Lifetime?)

面试经历

面试题

面试技巧

面试其它

本文一共 2568 个汉字, 你数一下对不对.

三次冲击谷歌软件工程师: 我的面试起伏录 (谷歌面试是不是一生只有三次机会?). (AMP 移动加速版本)

赞赏我的几个理由.

¥ 打赏支持

扫描二维码，分享本文到微信朋友圈

75a5a60b9cac61e5c8c71a96e17f2d9c 三次冲击谷歌软件工程师: 我的面试起伏录 (谷歌面试是不是一生只有三次机会?) 程序员软件工程面试

The post 三次冲击谷歌软件工程师: 我的面试起伏录 (谷歌面试是不是一生只有三次机会?) first appeared on 小赖子的英国生活和资讯.

产品设计和系统设计面试的区别(Product Design vs System Design)

小赖子的英国生活和资讯

JustYY.com 小赖子的英国生活和资讯

2024年10月26日 08:02

meta 产品设计和系统设计面试的区别(Product Design vs System Design) Facebook 程序员系统设计计算机面试

Meta / Facebook

在 Facebook/Meta 的软件工程师（包括站点可靠性工程师SRE和企业工程师EE）的面试中，产品设计/Product Design和系统设计/System Design起着比较相当重要的作用。

一般来说，编程面试（Coding Interviews)和行为规范面试（Behavior，考查是否和公司的文化价值观一致）是最基本的要求，而设计能力（系统设计或者产品设计）才是决定给你Offer的级别。

产品设计面试：Product Design Interview

目标：评估您创建以用户为中心的产品的能力，这些产品可以有效解决实际问题。
重点：您如何考虑用户需求、确定功能的优先级以及制定符合业务目标的解决方案。

典型问题

“您将如何设计一个允许用户管理其隐私设置的功能？”
“为 Facebook 上的新用户设计入门体验。”

评估的技能

了解用户角色和痛点。
打造直观且可扩展的用户体验。
平衡用户需求与业务目标。
分析不同产品特性之间的权衡。

关键方法：CIRCLES 等框架（考虑用户、想象场景、需求、削减和确定优先级、列出解决方案、评估权衡、总结）。

系统设计面试：System Design Interview

目标：评估您构建可扩展、可靠且性能卓越的复杂的分布式系统的能力。
重点：如何设计技术后端和基础设施以支持高流量和强大的应用程序性能。

典型问题

“设计一个像 Facebook 一样可扩展的新闻推送系统。”
“您将如何设计 URL 缩短服务？”

评估的技能

了解分布式系统和架构原则。
能够选择适当的技术（数据库、负载平衡器、缓存）。
了解可扩展性、容错性、数据一致性和延迟。
不同架构之间的权衡选择。

关键方法：使用 RESIST（需求、估计、存储、接口、可扩展性和权衡）等框架，并专注于应对技术挑战。

总结：TLDR

产品设计侧重于用户体验和产品功能。
系统设计侧重于后端基础设施和技术可扩展性。
两者的准备都需要模拟场景练习，但重点不同（用户需求与技术架构）。

Meta 猎头：

本次面试将重点关注系统设计和架构——考虑分布式系统和 API——非常注重构建/实现结构/产品。问题的一个示例：您将如何构建一个处理数百万同时连接用户的聊天系统？请务必非常透彻地解释，我们通常在白板上寻找一个方框和箭头图。

我还附上了几份白皮书供您阅读，它们展示了我们设计系统/产品的方法，希望可以让您了解我们在寻找什么（Haystack 是一个具有产品设计元素的完整系统的示例，即 API 和 CDN，其余的是更多的系统设计专注）。

英文：Difference Between Product Design Interview and System Design Interview