整个事件说白了就是阿里云的 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 倍，大多数情况下只能说明之前的实现太渣。
线上业务，应该衡量风险与收益，从能接受的方面开始优化。
项目情况不明的情况下，单纯来问一句“有没有必要”是得不到最佳的建议的——当然，有些人到网上也不是寻求什么正确答案，而只是寻求认同罢了。

对企业来说，满足基本功能的前提下，可维护性才是第一考量，性能、美观这些只要不影响功能，都是放在可维护性之后的。

买个低配云主机，用 gogs ，弄好异地备份策略之类的，基本上就没问题了。

恕我直言，大多数需要开发 /运维来发帖问这种问题的公司都不需要这么复杂的架构。

可靠性集群（ HA ）和负载均衡集群是两码事（虽然有时也能同时实现）。

Web Server 可以通过网络层做负载均衡集群也可以通过应用层做。

数据库这块，不管你使用哪种可靠性集群或者负载均衡方案都是要在某些方面付出一些代价的，这块的技术方案选型要根据实际业务要求来做。

生娃是你和女票生还是你和父母生？
养娃是你和女票养还是你和父母养？
买房是你和女票买还是父母买？
过日子是你和女票过日子还是你和父母过日子？

自己的福利自己争，指望别人，无非就是怕承担风险，又想享受收益。

不管什么方案都需要一个跳板机，剩下的就看实际情况选择方案了。
需求简单的话可以用 git/svn hook 实现，复杂的话， saltstack 之类的工具都已经很成熟了，挑个自己喜欢的就行。