@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 人的话就比较麻烦了，因为牵扯到无线的部分，不是靠论坛里说几句就能解决的。

找提高收费服务的比较稳当，顺便打个广告：深圳地区提供有偿服务，其他地区可以无偿推荐。

维权的话就两种结果，一种维权成功，一种维权不成功。
根据大多数人都希望别人出头冒险为自己争取福利的情况看，无论哪种结果，出头的人肯定会因为上班左脚进公司门被炒。
所以，直接换工作是最简单的方法。

1. 检查代码逻辑，看看是不是有什么漏洞——反正我公司的项目就遇到过一次。
2. 增加滑动验证码，貌似有个极验是做这个，其他家就不清楚了。
3. Web API 的话，增加签名校验，防止伪造请求。另外，还得考虑重放攻击的处理。
4. 后台判断出是攻击者的话，别直接报错、屏蔽之类的，而是返回假数据，但是不实际处理业务。（比如返回正常状态信息，但是实际不发短信。）

性能优化这种事情，如果你只做了一件事就把性能提高了 N 倍，大多数情况下只能说明之前的实现太渣。
线上业务，应该衡量风险与收益，从能接受的方面开始优化。
项目情况不明的情况下，单纯来问一句“有没有必要”是得不到最佳的建议的——当然，有些人到网上也不是寻求什么正确答案，而只是寻求认同罢了。