这点数据量谈个屁的大数据。但是对这种运营类场景来说，大不大数据的只是表象，关键是大数据这个词所对应的需求，是从另一个维度（ 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 。当然你这个场景是切换整套业务系统，那可能需要自己写一些逻辑来在接入层控制。

用缩进表示作用域层次的语言有不少，之所以 Python 会经常因为这事被拿出来说，还不是因为太流行了，阿猫阿狗都觉得自己能指点 Python

乌合之众、货币战争、黑暗森林，三大理论著作

看看 Mac 服务器端的日志

前有 RustDesk ，后有 MirrorX ，用 Rust 写远程桌面的大业方兴未艾

不要在旧版本的系统里自行升级基础组件的大版本号。
如果系统还在 LTS 期内，发行商会做好安全更新的，有时候甚至会 backport 。
如果已经不在 LTS 期了，那应该规划迁移到新版本。
自行做大版本更新，有两个问题，一是跟系统里其它程序的兼容性无法保证，二是你装完了在以后的使用过程中大概率不会随时关注自己安装的组件的安全更新，而发行版打包好的自有发行商关注。

VISUAL 、EDITOR 是“其它”软件需要起一个编辑器来交互操作时需要的，那你担心啥污染呢，反正都是你自己在 shell 下操作时才会跳出来，难不成你想 git commit 时跳 vim-enhanced ，vipw 或 visudo 时就用纯洁的默认编辑器？

另外，如果你只是介意 git commit 时 vim-minimal 报错，并不介意真的用 vim-minimal 写 commit message ，那是不是应该考虑在 vimrc 里判断一下 compatible mode 啊。