小孩子才分对错，成年人只看利弊。

我反正是很反感一些人上来就先贴个标签，带个帽子然后把别人批判一番——这跟以前的红卫兵小毛孩有什么区别？

技术选型、推进说白还是博弈，每个人的利益点不同。当然，有些人就根本不是理性经济人，这种人你就不要和他一般见识就好了。

如果当前项目管理方式没有问题，或者问题还不大——大不了加加班，也能解决。作为管理层，如果新技术不能带来“利益”自然是没什么动力推进的，再说了，很多混到管理的“大龄前码农”，下班了还得去抱老婆带孩子。学习成本再低那也是成本，而且风险再低那也是风险不是？

作为下面的码农，这些依赖管理工具， CI 理念又不能直接加工资，毕竟大多数公司招人最重要的还是靓丽的履历表，那些高大上的技术关键字才符合 HR 的基本价值观。

道不同不相为谋。楼主稍微推一下就行了，公司项目代码管理什么的就别掺和了。该继续加强自己就继续，没什么加强的就准备换换环境——就算没法改变世界，改变一下自己还是可以的。

带宽不够的话，还是得泡咖啡。:doge:

内存是 ZFS 的要求，保障性能和安全的前提下大容量 ECC 是必要的。不过其实你用非 ECC 内存， 8G 容量也能跑得不错。
如果不是非要 ZFS ——这个得直通硬盘控制器接硬盘，否则真心没必要，选 OMV 还是不错的。

@Felldeadbird 挤过公交或地铁吧。你会发现空车来的时候排队是很有秩序的——因为有足够的空间容纳所有人。但是如果车厢人很多，明显无法容纳所有人，并且可以预期一段时间内都是如此，再来看看队伍的秩序。

支付宝做社交更多的是一种防御，因为微信这个”社交“应用做支付了不是？进攻是最佳的防守，所以支付宝的社交各种不走心（个人纯吐槽）——要知道一个公司能做到这么大体量也许有各种弊病，但还不至于大多数人都是傻子，不知道用户的各种吐槽和反感。

说到底，如果多数用户选择”免费“，那么为了盈利 /生存选择其他方式是必然，虽然程序员不需要养家，但是电脑、房租、水电、宽带还是要钱的嘛。:doge:

所以说，与其吐槽，不如掏钱买个 office 订阅吧，巨硬双 11 office 个人订阅版有优惠哦。

@Felldeadbird
产品或者说公司能存活至少能说明市场是选择了它的，也可以说是用户选择了。所以说金山变成现在这个样子是用户先动手的。

如果今天你觉得 WPS 渣，转身装了盗版 office ，不好意思，金山也许只能流氓下去。

PS ：感觉金山应该出个类似 office 订阅的个人版本，把各种推广收一收，不过估计是懒得处理各种破解吧。

说出来你不信，是用户先动手的。:doge:

占美， nuc ，戴尔微型台式机
配置看预算选档

放宽心，现在跳出来就要自己做支付，自己做直播，自己做导航的公司也基本都是作死，不去也好。:doge:

整个事件说白了就是阿里云的 IO 差罢了。不过 ECS 的 IO 必须差啊，否则 RDS 卖不动。:doge:

个人记忆中最开始阿里云只有普通云磁盘，那时候虽然随机读写很渣，不过连续读其实还是够看的，不过阿里方面也没有明确的文档对 IO 这块进行说明或者承诺。

后面推出云 SSD 和增强云盘后，才开始有 IO 这块的说明，实际使用看——普通云盘的 IO 确实降低了。

不是很懂 PCB 制作，不过个人理解，小批量，想价格便宜又质量稳定是不现实的。

这套路又不是 it 行业特有的。

发布一个高大上的招聘岗位，反正要求是很多，薪资往上标，表示公司不差钱。

实际上真来了个完全符合最高要求的，其实根本不会要——因为根本就没打算出这么高的薪资。

对于那些满足真实岗位需求（甚至超过一些）的人呢，一方面压低薪资，一方面还会使用“是公司给你机会”、“要感恩”之类的洗脑术。

@ivyliner

我待的是小公司，各种问题用比较脏的办法解决对我来说是“最优”的——懒才是运维的必要特点。

运行 /编译环境问题，要开发和运维一起坐下来解决掉，如果进入各种撕逼的节奏，我想到的办法就是让开发交付二进制编译成果。

我也知道这个办法不是一个好办法，不过至少能快速解决我的问题，减少撕逼时间。

@dennyzhang

如果是直接从 SCM 中签出的话，我觉得文件校验这块版本控制系统是应该有做的——毕竟这个问题实在是太低级了。

小公司项目连文档都没有，更不谈专门写什么测试用例了，反正我只是校验了下配置文件，剩下的就是纠如何自动的实现搭建一个最接近生产环境的测试环境，还得不影响生产环境（公司项目是.net 平台， windows server ）。

至于后面的问题，慢慢找资料解决了。

准备试试 windows server 2016 的容器功能，虽然公司肯定不会让我用这么新的版本到生产环境。

最大的坑在于：合同完全没用。:doge:

@acumen 单个 ap 带机量是有限的，单位空间内的 ap 密度也不能太大（这点可以通过降低无线功率来提高密度，变相提高单位空间内的可接入无线设备数量）。无线来说，信号强和信号好是两码事情（信号强度和信号纯净度决定信号质量）。

设备少的情况下网络卡、慢通常都是因为应用占用问题，特别是上行这一块，所以通过网关做应用层控制，可以有效的提高网络质量——但是，确实是出口带宽不足的话还是无法解决。

设备多的时候，情况就复杂得多，需要先定位到网络瓶颈才能继续。当然，不差钱你可以无脑提高出口带宽来解决有线的问题，但是无线这块，确实不好弄——特别是还牵扯到安全接入这块。

1. docker

2. 让开发交付编译好的二进制文件，直接提交到版本控制系统中，使用配置文件进行各项配置（数据库，各种 key ，参数之类的），这样只需要对部署后的结果进行对比就行了（ md5/sha1 ），当然配置文件可以直接使用文本对比差异。

3. 对关键部分增加自动测试环境，比较检查基础配置项目或者业务逻辑之类的。

4. 把开发用的机器拖到生产环境去当服务器。:doge:

@acumen 20 个人比较简单，基本上弄个带应用层流控的软路由（爱快、 panabit ）就可以解决， 100M 出口以下的话，用虚拟机跑都可以。

300 人的话就比较麻烦了，因为牵扯到无线的部分，不是靠论坛里说几句就能解决的。