2
自我介绍
这一段，每一家公司都会有，虽然偏于形式，但认真对待，事半功倍。我的建议是写出来，背下来，并注意观察是否能体现自己能力及在团队中的贡献。更进一步，要注意体现自己的产品业务能力及管理能力，业务能力在同类业务公司及其有用，可以是营收(体现市场规模)，竞家，产品的区分度及优势，或者解决的痛点。管理能力可以是对技术基础设施的建设，项目掌控及团队管理。
业务及产品简单介绍
这一个问题，偶尔会问 到，一般是在三面。简而言之，对业务要有相当了解，这要求平时与产品多沟通，并多多点击自己做的系统。(可以由公司业务启发，抽离痛点，点醒 SideProject，从对业务的深入理解实现与公司的双赢)
讲解下 node 的线程模型
这个问题我答的不太好。要理解 node 的线程模型，首先要了解 node 的架构，node 的底层是 libuv，v8 两大支架及一些较小的依赖如 node12 中引进来更快的 llhttp，c-ares，icu-data，zlib 等。因此要学好 node，则要了解 libuv 以及 v8 两大块，其一 libuv 与事件循环息息相关，无时无刻体现在你的代码中，而 v8 与 cpu/memory/gc 相关，无时无刻体现在你的线上问题排查中。关于线程更多的问题，可以参考 浅析 Node 进程与线程(opens new window)
在线上如何排查问题
- sentry 监控，根据监控中的异常代码，异常及异常相关上下文(如请求失败，则失败的 request，数据库查询失败，则失败的 sql，以及附加的用户信息等)解决问题，未果，往下走
- 根据 requestId 获取全链路式日志，在日志中查找蛛丝马迹 (需要借助 APM)
- 阅读日志相关业务逻辑
- 测试环境尝试复现并解决
使用了 egg 了没，讲解下 egg-cluster
- 没有，不过这个问题问到了很多次，看来 egg-cluster 确实应该研究下
线上的 OOM 如何解决
- 每次上线时紧盯 prometheus/grafana (线上部署基于 k8s，因此对于 deployment 的监控比较简单)，如有异常，排查本次上线新上代码 (根据运维方式解决，大部分问题在这里解决)
- 如果从运维角度无法排查，进入容器，借助 heapdump， 发送 USR2 信号，抽离 dump，下到本地，并在 chrome devtool 中分析
你们线上流量大时，如何解决
如何防止服务雪崩
你们数据库为什么采用 postgres，它有什么好处
- 更好用，对于 jsonb 及数据分析更加友好 (老大们选的，我整体对于数据库偏弱了)