fail2ban 、改受限 shell ，也算是短平快的辅助手段了。但一般来说这些只是辅助手段。根本的还是认证安全 /网络链路安全。

既要又要还要是不可能的。脱保了而且连源码都没有的系统，又不打算重新开发，那只能通过堆屎山的运维手段来缓解了。

首先要在服务器端更新系统组件，这是必须做的。多年不更新，鬼知道哪个 CVE 会暴雷。当然如果服务器端操作系统比较老，比如 CentOS 6 这样的，就算更新到最新也很老了。可以自己编译安装较新版的 OpenSSH ，不过不要替换系统自带的，可以安装在另外路径，系统自带的停掉，用新的来服务。不过这样做了还是要自己日常关注 OpenSSH 的安全通告，必要时手动升级。

另外，你的意思是客户端程序里调用 ssh 登录，登录成功后做了端口转发，而且是程序内部代码实现的，不是调用外部 ssh 命令，现在没办法改了？（如果是调用外部程序，就可以用加套的方式替换）

客户端程序的行为没法改，不等于运行客户端的环境没没法动。#19 说的“无论是 VPN 还是 Knock, 都离不开客户端改造”大概意思时连运行客户端环境都没法动的情况。如果不是他说的这样，其实是可以认真考虑用 VPN 的。当然如果要运行客户端的是各个非 IT 的业务员工的家里，那部署 VPN 会造成心智负担。要么做好培训和支持，要么另行开发易操作的部署程序，都会比较折腾，但并不是完全不可行的。

然而国内如果城市面积小了大概率不会是发达城市。

后端返回 4 了前端还“自己感知不到”？正常设计里难道 4 不是表示后端正常、前端传的数据有问题？“如果后端接口报错了，前端就会把这些记录继续暂存在前端”，难道你们的设计是后端接口返回任何非 2/3 的代码前端都当成是后端出问题了？

大部分程序员写不好多线程程序。

https://www.talkwithtrend.com/Article/253491

这篇讲得比较现实。

个人浅见，在考虑这个问题时，需要问自己的实际问题：为什么要部署到容器？想针对传统方式的什么痛点（这里只说生产环境，开发环境一句命令拉起来的便利性是另外一回事）？部署到容器后解决痛点了吗？需要为容器化的数据库运维改变什么思维方式和配套工具，这些付出否合算？

这个方向，民间自己搞本来就是灰色地带，再加上在福建的…

@adoal 说错了，是根据 ntpq 返回结果里的 offset 、delay 、jitter 看同步效果。

offset 、delay 、jitter 可以调调看。

@fengleiyidao 不能 ntp 机制本身不能保证你提出的这个量化的硬性要求。你设想的过几秒定时运行的办法，也不能保证做到这点。

不过 ntpd/chronyd 可以通过 minpoll/maxpoll 参数来设置定时同步的周期范围。还有其它一堆参数可以慢慢调的。

要更靠谱的话得本机接一个硬件时钟源。

所以你在生产环境都是每个业务系统的数据库单节点跑，不做主备不做集群不做故障转移切换不做浮动 IP 不做读写分离，一个 C 段里混跑各种业务系统和数据库，一句 yum/apt 或者 docker 拉起来的单节点数据库实例就敢上线吗？

以上 ntpdate 和 ntpd 是举例。chrony 也可以。

另外，成熟的发行版，安装时间同步管理套件时会在启动项里配置好上面这个流程。

ntp 的时间同步机制不是这么用的。

一般用法是在系统启动阶段 ntpdate 强行同步一次，然后启动 ntpd 在后台慢慢维护时间便宜。开着 ntpd 的时候，ntpdate 会拒绝运行。

尤其时在服务器环境里，因为有不少服务软件假设时间是平滑、单向进行的，如果在服务软件运行过程中突然发生时间跳变，尤其是回拨，软件的逻辑就会出错。所以正确的用法是 ntpd 在后台持续运行，跟上游时间源对比，如果偏移量超出阈值，就小幅度调节内核时钟的进行速度来纠偏。这个调节是平滑的，而且如果本机时间超前了也不会回拨，只会减慢进行速度。而启动阶段强行 ntpdate 同步一次的原因就是如果偏差太大，ntpd 的缓慢纠偏机制不给力，而启动时 ntpdate 会安排在大多数业务服务之前启动，这时候任何时间跳变都无所谓。

只要你不**，**的就是别人。可以替换成各种词。

UBNT 的答案是：①R 默认不开启，用户自行开启时会提示可能有兼容性问题。②以前出过一个 zero handoff 方案，各 AP 用同一信道，但因为这样做对布点要求太高，需要提前勘测和设计，后来就不提倡了。

“码农”是对职业的描述性称呼，类比于“戏子”，而不是在对话的时候直接面向第二人称个体的指向性称呼。先不论观点，你标题的对比，在语义层面就是不匹配的。

如 #2 所说。

你的 SELECT id 是在哪里运行的，怎样算是“出结果”？

都成年人了，就不要为了别人好而改变别人了