只要你线材、插座、电源是合格的，火灾应该不会，但是织物会容易掉纤维（这就是为什么卧室地上总是会有毛毛），时间长了机器里面会容易积灰。

我是放木质电视柜里（关门），左右两侧开 14cm 的洞用猫扇通风，里面除了网络设备和服务器没有其他东西。

实在担心的话你买个烟雾报警器啥的放里面，附近放个灭火器啥的。

@ruixue #39 虽然但是，题主要求“不要很费劲捣鼓支持远程，安全性高”，我觉得至少得用成品机+全新配件。要是肯折腾，对可靠性要求不高，垃圾佬方案一大堆。

想跑 docker 的话，通常就得用 x86 的 NAS 了吧，不是说 arm 不能跑，对各种镜像的兼容性肯定还是 x86 更好一些。

最大问题是预算，先不说 3k 是否能买到符合你要求的 NAS 主机，后续会有不少再投入，比如你需要备份数据，那么需要额外的钱买硬盘或者线上存储服务，有的文件系统需要加内存，还有的文件系统需要换更贵的 ECC 内存，用 RAID 的话还得额外配一个 UPS 。

一块 NAS 专用盘 4TB 得七八百吧，要想上 RAID 的话至少得 4 块吧，如果换企业级大容量盘一块也得一千多吧，关键企业级盘噪音还大，你有 4 块负责提供服务的，再来几块用来备份的，跟机器一起整体全加起来估计得需要五千到一万的预算了。

当然你也可以说这些所有你都不要，你就搞一个 2 盘位的品牌 NAS 就行，也不备份了，也可以接受小品牌，那么 3k 应该差不多。

我家一般是因为窗户太密封，开扇窗就好了。

有问题的不是去医院、挂水、住院，而是大多患者或家属不懂医学，要求治疗立刻、马上见效，因为经常有这样要求的，所以医院就自然而然把这种治疗方式作为默认。

当然医院也有坑钱的、资源紧张不给看的、过度谨慎的。

我就遇到一家过度谨慎的医院，还是三甲，小儿问题一律要走一遍排查，把症状相关的可能的严重问题都排查掉之后才当成普通病症治疗。你说合理吧，大多患者都没有严重问题；你说不合理吧，万一没查出来严重问题可能就耽误治疗时机。

我是觉得这类问题的解决方案从来不是讳疾忌医，而是一方面自己学习一些基础和常见的医学知识，具备一定的判断能力，另一方面想办法找到可信、可靠的医院、医生。

是自己治疗试试，还是去医院查个明白，反正孩子是自己的，根据自己意愿做选择就好。

设备硬件、系统、加密算法、数据处理服务，为啥那么大力度要推国产化，先不说情报部门是不是挖出来了点什么，被其他国家报道出来的间谍事件就不少。

比如前阵子白俄总统专机被远程锁引擎，德国因为默克尔被监听而强烈谴责。

马斯克审计完亲自发帖证实任何美国社交媒体都受美国政府的管控，还一堆人拿“私人公司”洗呢。

反正一样的事情发生在中国就是没有言论自由，发生在美国就是私人公司的自由。

预告一下后面肯定有人抛开事实不谈让我多“关心国内的问题”。

电压一样就可以，功率越高电流越大，线材能承受就行，你可以接上之后测一测线材温度。

互联网经营性业务的话，还会有其他一系列合规要求，家庭部署这块单网安方面都满足不了，比如灾备、机房管理、消防等，当然网安真要做到及格线的话八成成本就已经高于云平台了，而且你业务量小的话监管也不会注意到你，大概率也没人要求你做等保。

其他的就是看宽带协议里是不是有不允许商用的条款，不过只要不是流量特征有异常，运营商应该也觉察不到。

综合看来貌似可以开干试试。

我上个帖子就分析过了，题主可能是个好的技术人员，但不是一个好的管理者，不清楚两种岗位的区别。
简单来讲，开发/技术专家更像是玩 RPG ，而管理岗更像是玩 RTS 。

当然，也可能是上级没有对你进行培养和引导，或者造成了你对你工作内容的误解。

下个工作找个架构师挺好的，关注于技术应该比较适合你。

几百部电影已经手动整理改过文件名了……

@gotosre #3 所以我说的是适合只上传不下载，上传流量是不收费的，如果作为兜底方案的话也几乎很多年都不会下载一次，未来换其他方案也可以在平台上一删了事。

用机械还是 SSD 取决于你对读写性能的要求和预算，保障数据完整性的核心手段是备份，用啥存储介质无所谓。

可以增量备份的话，你可以研究一下云厂商对象存储的冷数据归档服务，适合那种只上传不下载，极端情况下需要有数据可以下载的场景。

@ltltfuture #30 大数据基础设施虽然我们也有，但我并不是很了解实际内部工作流，我只是把原始需求提给了大数据架构师。

我尝试理解一下你描述的场景。
首先不同的环境要用不同的 credentials ，dev 肯定和正式环境的不一样，这样即便 dev 的泄漏了，也不影响正式环境。
其次我不清楚你们的 dev 环境是不是由运维或专人全权维护的，如果是的话那么就和线上正式环境一样，仅专门人员可以访问和操作运维环境，使用外挂的方式管理和向服务注入敏感信息。只要运维环境的访问权限限制死，用 CI/CD 来实现手工注入敏感信息也是可以的。

这需要你们有一个相对健全的 DevOps 流程，如果开发兼 dev 环境的运维，肯定就没法把敏感信息分出来了。

我去年做了一个项目，在全公司设立制度禁止在代码中包含敏感信息。提供了多种整改方案，比如用 k8s 的 Secret 、环境变量、数据库或 K-V 存储来保存敏感信息，开发人员禁止接触敏感信息，仅获得授权的运维人员或负责的业务人员可以接触到。

现有的、已经在代码中包含敏感信息的情况，要全部更换敏感信息，比如重设密码、重新生成 token 和证书。

开发、预发布、线上环境采用不同的认证凭证。