不过你这个确实也是问题。还是要加上检查的。

搞等保那批人懂个屁的安全

就技术而言，他们虾扯蛋。就实际工作而言，看博（撕）弈（逼）结果吧。

路由器是用 squashfs + overlay 或者其它类似的方式，squashfs 是一个压缩率很高的只读文件系统，如果需要改动，有两种办法，一是需要运行时随时可写，就加一个 overlay ，写的东西在 overlay 上，二是单独建一个可写文件系统，需要把改动反映到主系统的话重新打包 squashfs 。

财务：这服务器买的值……但可不可以利用率更高
运维：已经需要考虑业务波动带来的可用性风险了
开发：程序是否有较大优化余地

因为低水平（并且敢在简历里吹高水平）的人是大多数。
结贴，散分。

“迫于”这个词在 v2 都滥用成啥样了啊😓

看看是不是 shell 的某个 rc 里 flush 了

你在三个回答里都说需求蛋疼讲不清楚。
所以我怀疑这是个 X-Y 问题。
也许你自己梳理一下原始需求，好好组织一下文字，表达清楚了，也就知道是怎么回事了。

@violence123456 讲真，我看不懂你的表达。
另外我没做过底层网络开发，只是凭运维人员的经验觉得这样配置很扯淡。

两张网卡插在同一网段配同段 IP ？你确定真要这样做？这可能是一个 X-Y 问题。

syslog 可以配置过滤，可以配置打到远程服务器。
对老派 Unix/Linux 用户（甚至只是用户，不是职业运维）来说这些都是挺基本的技能。
不过貌似云时代的 PPT 架构师们都不太把这些老派的玩意当回事😄

换个思路，你是写业务系统的程序员，这些“运维”性质的功能不要在业务系统里自己写，要善用现有的基础设施。

如果只是在 Linux 用，不考虑兼容 Windows ，可以打到 syslog 去，然后由 logrotate 来卷。正常的 Linux 发行版，默认安装都带了 syslog 服务（多数是 rsyslogd ）和 logrotate ，人家是专业干这个的，久经生产环境考验了。

没有运维知识的纯程序员往往会把什么乱七八糟的需求都用项目的主编程语言写到主程序里面去。其实呢，你的程序在生产环境运行时，可以外面包一个 sh 脚本来启动，把清理数据的操作单独写一个几行的 py 在 django 之前运行不就可以了嘛。

如上所言，就这个问题来说用-y 参数……

但是，在目标服务器上安装发行版里打好的包，这种应该是 prerequisite 工作，放到程序内部作为一个业务逻辑，一般不是很建议。这样会让本来应该准备好服务器部署的人更加被宠坏。

作为体制内的甲方，我只能说，就是这么扯淡……
不过这种明显短得不合理的 deadline 很可能是因为甲方自己管理流程（大单位的，不是具体负责项目实施的小单位）导致的实际开工比计划拖了很久，但是经费支付 deadline 按制度又不能拖，所以要搞一个形式主义的验收，实际工作很多是要在形式验收之后。

http header “Host”

通常问选什么数据库是针对自研项目，那我会无脑推荐 PostgreSQL ，但如果是部署已有的 SNS 类 CMS 系统，支持多种数据库，那选 MySQL 大概率是对的。
Drupal 之类的也都是这样，核心系统可能支持多种数据库，但是第三方生态里的各种插件常常是 MySQL-only 的，没有对其它数据库做过充分测试，或者完全不兼容。