js8510

Python + flask/django. FastAPI 的问题是是暂时 community 不太成熟。比较有经验，有信心去 stackoverflow 自问自答的朋友可以尝试 fastAPI

thinkpad 小红点？似乎更靠谱一点。

我遇到过类似的。最后使用 presigned url 稍微增加了 手动 call api 的难度。

1. client request for address updates -> server
2. server return a presigned url for posing address chagnes and the url timeout in 200ms(一般是你 request response round trip 正常的时间范围)
3. client update address with presigned url.

因为 2. 返回的 presigned url 有 200ms timeout 而且只授权指定 ip. 所以，至少用户没办法手动操作直接 call api. 怎么着也要再搞个脚本 自动化一下。其实就拦截了不少特定场景下的用户了。

但是我觉得你的用户如果都是程序员，而且直接 call api 的动机很强，那基本上就没有用了。

为什么是百度一下。。你这是不是正经 Google

我在国内用过 pixel 。。有梯子就还好。。但是国内很多 App 比如地图会不太好用。。请求一堆权限，然后很多原生 google map 能实现的东西都没有。。没有用的东西一大堆。。 但是 google map 在国内又是个废柴。
反正我是不会长时间用，水土不服。可能没有国产手机丝滑。

看你怎么定义 “运维”。。
我是 oncall 过比五万台更多的机器的服务。高度自动话以后。。其实 5 万还是 10 万台机器，差距不大。manual operations 也不是很多。。甚至有>50%的时间写代码，开会什么的。更多的就是：
- 工作时间 alert 都看一看。
- 非工作时间 高 priority 的 alerts 看一看。低的直接忽略。
- 出事了有各种 data set, logging 。 有经验的话很快就能找到问题大致方向。熟悉了（因为出了 SEV 都要 review 的）也能知道大致会经常遇到的问题。
- 搞不定就把别的 oncall 拉起来。怀疑 downstream 拉 downstream .怀疑是谁的 change 就把谁叫起来问。纯粹需要帮助也可以拉别人起来。
- oncall 结束以后总结一下，noisy alerts 想办法调一调。有些简单的问题想一想能不能搞个 auto remediation(比如有些情况明显是 auto-scale 有问题，那就在这种条件下让他自己关了 and scale to max size 等第二天上班时间再解决。这样你非工作时间就不用搞这些了。。还有比如某些 feature 还不问题也不中要，那你监控到它挂了直接给他关了然后把 alert forward 给 onwer 等天亮了再说 等等等).

所以我觉得是需要点经验的事情。。但是多数时间一个人搞的定的。当然偶尔也有倒霉的时候。

一直都用 click. 不过看了这个 fire 感觉好棒。下次有机会试一试

对追求高性能的大型服务后台影响非常大。这些 binary 为了追求极致性能，常年反复压榨，往往把编译器能用的所有 option 已经调了一个遍，全都要重新做。另外部署的时候各种多线程的优化，kernel 层面的已有优化，甚至是代码风格的要求都会有变化。

Linux Device Drivers, 3rd Edition https://www.amazon.com/dp/0596005903/ref=cm_sw_r_cp_apa_glt_fabc_PCXGXFHSRPM7F25AT88E 我觉得是比较有意思的一个。因为你可以跟着写写 helloworld. 缺点是书太老。。你得自己 google 照着书敲代码多数不 work