一次面试结果的反思

一次面试结果的反思

本文来自依云's Blog，转载请注明。

很久以前的事情了。现在终于不再感觉到那么累了，想写，所以才写。权当日记吧，就懒得加各种链接和排版了。

这次的面试目标是百度运维工程师。

问题：为什么 Arch Linux 中文社区源的自动打包服务是自己弄的，而不使用现成的 CI 呢？

其实原因很简单：没想到。因为 lilac 自动打包脚本是由功能更简单、自动化程序也更低的脚本进化而来的，比如 nvchecker 更新、曾经自己用过的一些辅助脚本等。

当然，即使想到了，我也不会去用的，因为需要定制的东西太多。更新检查、依赖处理、错误回报、git 仓库管理什么的。传统的 CI 不像是天生支持这些的。最接近的 OBS 大家也知道，对 Arch 的支持很差。当然我可以进行二次开发，但工作量会很大、耗时会很长，因为那是我需要从头读文档、学习、尝试的一套系统，而对于 Linux 编程、Python 编程，我已经非常熟悉了。至于可重用性？首先我要解决它的可用性，东西都做不出来了，何谈可重用性呢？

当然 CI 系统对资源的消耗也不能忽视。

这个问题挺意外的，面试的时候没想这么清楚，没答到重点。

问题：为取得网站的高可用性，防止单个服务器挂掉影响整个服务，要怎么办呢？

我的回答是通过 DNS 和 anycast fallback。哪个服务器挂掉了就不用哪个了。DNS 的更新有些慢，在 DNS 应答中返回多个 IP 地址用处不大，大部分客户端都只会尝试第一个，我见过的只有 wget 会锲而不舍地穷尽一切方案去努力。Anycast 反应会更及时一些，CloudFlare 就喜欢用这个。

但是标答是 LVS。好吧这个词我没研究过。回来上网去看了一下，Linux Virtual Server，就是在前端放个负载均衡啦。我没有想到这个。今天我终于想到我为什么没有想到这个了——LVS 还是一台服务器嘛，只是逻辑上的服务器。作为一名程序员和数学爱好者而不是电器维修工，我对各种物理上的东西没什么深刻印象，反而对各种抽象的概念情有独钟。所以我自然而然地把「单个服务器」理解成单个逻辑上的服务器了，而不是或大或小的铁盒子。也就是说，我的理解是，当这个 LVS 系统挂掉了要怎么办。

我再一次把面试官想得到的答案当成了理所当然……

问题：正在进行通讯的两台主机之间的「网线」断了，一方再发送数据，这时会发生什么？

这个问题也很不明确，存在多种可能。

最简单的，直接连接发送方的网线断掉了。内核会收到硬件传回的信息，「carrier lost」，然后相应的路由表项被删除。就跟把相应的网络设备 down 掉一样。什么都不会发生，连重试都没有。应用程序就在那儿等着。

如果是位于局域网中，情形也差不多。只是会进行 TCP 重试，然后 ARP 广播「找人」。

互联网上的话，如果还有其它线路可用，数据包会走其它线路。如果所有线程都不通了，应该会返回 ICMP 主机不可达或者网络不可达。不知道这种情况下 TCP 和应用程序会发生什么。没条件实验。学校网络课实验自然不可能搞这么「高端」的东西。

当然，这么些可能我当时也没想全。

我发现我面试的时候思考能力变得很差的样子。其实凡是被人关注的时候都会发挥失常，虽然没有严重到别人盯着就写不出代码来。这也是我在社交活动常不满意的原因吧。