给领导准备好热水和布洛芬吧

代味（代码的滋味）

看了一下，我当年为了搞这事收藏的几篇文章（包括 OpenWRT 和 EdgeRouter 上的）都失效了……

dnsmasq-full 包根据目标域名给解析出来的 ip 打 ipset ，然后防火墙规则里对指定的 ipset 做 mangle 配合 ip rule 走路由规则

前一半自己搜搜，目标域名还有 gfwlist2dnsmasq 这个工具可以用来生成。后一半大体可以参照这篇 https://oogami.wordpress.com/2015/05/31/linux-%E7%AD%96%E7%95%A5%E8%B7%AF%E7%94%B1%E4%B8%8E%E5%A4%9A-vpn-%E5%B9%B6%E5%AD%98%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5/

不过照抄是不行的。

运维岗的面试不应该问这么宽泛的问题。哪怕是招运维负责人。

PSK （公用单个密码）的问题是，如果无心（或有心）泄露给无关人员，或者被 WiFi 助手泄露，是没办法追查责任的。

那就说明你不需要。那你就不用改呗。

不是很冷的知识：王院士是工程管理学部的

这点数据量谈个屁的大数据。但是对这种运营类场景来说，大不大数据的只是表象，关键是大数据这个词所对应的需求，是从另一个维度（ analytical ）去理解业务发展，跟原来的维度（ transactional ）很不一样，思维模式、需求侧重、技术指标都不一样。所以总的来说还是个值得利用的好机会。至少可以试试看自己是否有这方面的天赋。实在做不出感觉来，以后重回 transactional 的业务开发也不是不可以。

这是在纵容事发公司后续依然不重视运维

再比如，用 logrotate ，我可以配置 pre 和 post 脚本，在 rotate 动作的前后做一些处理。

而 rotate 功能做在 application 内部了，怎么办呢？让写 application 的业务开发团队加这个功能，然后业务开发再去推写 log 库的人加这个功能？就算实现了，谁能保证专注于写业务的开发团队顺手做的能比人家 logrotate 一心一意做了这么多年积累下来的经验更可靠？那我当然是希望业务开发团队不要操心这些事情。

另外，不是说日志库完全不需要考虑 rotation 。只要留个操作，可以 reopen 当前的日志文件就行了。外部 rotation 工具在移动日志文件后往进程传一个 rotation 指示（比如 kill -HUP ），进程收到后 reopen 日志文件，就写到新的文件里去了。而不需要在日志库里对日志文件的更替做定时管理。日志库里要再加上这个功能，那又要牵扯到定时任务管理，更加复杂了。

@yuancoder 那有什么必须的理由把 rotation 做成 application 的一部分而不是外部功能呢？

作为一个运维人员，我想到用外部功能来做的主要理由是，logging 虽然不属于业务功能，但毕竟还是应用系统的一部分，属于业务发出的动作，而 rotation 则完全和业务无关，是“带外”操作，其逻辑本身就是外部化的。rotation 跟业务逻辑没有什么必然关系，生产环境所要维护的 rotation 操作，外部化之后，可以用专门做 rotation 的组件来配置足够复杂和灵活的处理规则，这些没必要让做开发的角色来操心。这种解耦有利于业务程序员和基建运维发挥各自的长处，各司其职，而不是业务程序员操心基建开发，在“进程内”造轮子，运维又要学习一堆繁杂但又不见得比现有成熟基建更强大的专用配置来吐槽。

另，以上不针对功能性的轮子。只针对日志切分、旋转这种运维性质的杂活。

其实大多时候打到 syslog 去让 rsyslogd 和 logrotate 去处理日志运维的杂事（比如切分）就够用了。

哦，用 Windows 的请直接无视我。

不清楚 amazon 的 api gateway 是怎么做的。只用过 Kong ，会把 consumer 的身份通过 http header 传给后端。

X-Consumer-Id
X-Consumer-Username
X-Consumer-Custom-Id
X-Credential-Username
X-Consumer-Groups

灵魂拷问：你的业务是否真有频繁发版的需求？

做 CI 也就罢了，不论发版是否频繁，CI 都是应该做的。但是做 CD 的话，是真的能提升交付品质，解决业务痛点，改进用户体验，还是为了 CD 而 CD ？

A 和 B 的访问通过一层反代或者其它接入方式（比如浮动 IP ）控制，用户和开发不直接连 A 和 B 。在接入控制层，生产环境总是固定为一组网络资源，预生产环境总是固定为另一组网络资源，往后端接入时，根据切换映射到不同的实际资源。

类似某些主备数据库集群里常用的做法，A 有固定 IP 1 ，B 有固定 IP 2 ，两者一个是可读可写的主库，一个是只读的备库从主库同步数据过来。当现任主库挂了时从库提升，运维人员去修复主库。浮动 IP 3 永远飘到现任主库上，浮动 IP 4 永远飘到现任备库上，当主库降级修复时 3 和 4 都在新的主库上。这样，不论 A 和 B 角色怎么调整，应用程序要访问主库就用 IP 3 ，访问备库就用 IP 4 。当然你这个场景是切换整套业务系统，那可能需要自己写一些逻辑来在接入层控制。