这槽太深，没看懂

1楼 @tinyfool 简单而言，app server 本来应该可以直连 internet 的，因为 DynamodDB，SQS 都是云服务，需要 internet 连接的。公司的安全官员，出于所谓的安全考量，统一要求所有 App server 必须经过 proxy。

AWS 可以自动的帮你加服务器，如果检测到服务器 CPU 太高或者流量太大的话。

如果没有 proxy，只要把 app server 进行 auto scale 就好了；现在放在 proxy 后面，为了防止 proxy 成为瓶颈，他们都需要设置 auto scale。

proxy 不但让 end to end 的时间变慢了，还增加了成本。

不过他们不 care。

仅此而已。

头一次看到真有人这样用SQS的，有点穿雨衣洗澡的感觉。

公司做部署的人不同意，说这是 CXO 的意见。我当然识趣，也就不去 fight 了

我发现很多身边的朋友工作中都是这个心态，不过很少在老外同事身上看到。其实工作中就应该坦率表达自己的想法，既锻炼表达能力，也会赢得更多尊重，一个有想法不表达出来的牛人，在其他人看来和一个和没想法的庸人一样，长期以往，个人就陷入满腹牢骚，怨天尤人的状态，甚至觉得自己受到歧视都有可能，而在其他人看来，这个人就是一个很普通，没想法，但是态度越来越恶劣的一个员工了，这多悲催。

4楼 @coredump 赞！ 所以我都快成了我们组里最会吵架 的人了。 不过有时候很容易给人一种固执的感觉，所以要把握一个度

5楼 @hellojinjie 要点就是，去用事实（数据，代码，逻辑等）说话，不要用情绪说话，外加适当幽默和自嘲做润滑剂。没有一个正常的CXO不喜欢这样的手下，如果真的有这样的CXO，那么也是好事，你就知道不应该继续待在这个公司浪费生命了。

4楼 @coredump 因为不是吐槽的重点，所以我省略了部分故事。

公司的AWS production子网之所以设置成这个样子，是因为大多数项目都是普通的网站。他们只需要直连 RDS 。而 RDS instance 都可 launch 在 VPC 内。即使 VPC 子网不能直连 internet，他们也可直连子网内的 RDS 。绝大多数 production 服务器都不能直连 internet，甚至没有去 proxy 的 route 项。这样的配置的确是挺安全的。

我们项目有点特殊，之前讲过是用 DynamoDB 跟 SQS，都是在云上的。不仅需要 internet，而且是越快越好。直连当然是首选。后来发现，即使有了 proxy 也不会慢多少。我用实验的 AWS account 建了一个可直连的子网，然后做了benchmark，比对了 production 的 benchmark。发现的确是有性能差异，但是只有 10ms。我们性能要求 130ms 内，实测（含有outbound 和 reverse proxy）60ms 上下，已经超额完成任务了。

我们 production环境中已经有很多其他项目的服务器在跑了，老大们肯定不会同意贸然修改的这些基础的东西。

现有 solution 除了稍微慢一些，唯一的问题就是需要多花点银子，不过公司似乎一点都不在乎。

其实我觉得可以改进的地方是应该一个项目一个子网或者 VPC，然后不需要像这样一刀切。不过 operation 的人可能不大愿意这样做。

7楼 @minddriven 虽然你提到的很多东西我都没用过，有点不明觉厉。不过我觉得你纠结的地方在于作为一个基层工程与CXO对待运营成本的角度不同的问题。你提到的一个项目一个独立的开发环境和网络配置（是这个意思吧？），是理论上最合理的方法。我不能说你是错的，也不能说那个CXO和Operation是对的，但我的思想是，如果你坚持你的观点，也希望提意见，那最好先和Operation打好关系，了解他们的工作的繁重点和复杂度在哪里（我不确定你是不是很了解），有可能他们的资源处理不了你所期待的需求所需要的管理复杂度，也有可能是他们功能能力问题。从CXO角度来说，表面“省钱”并不见得是第一选择，也许综合下来你期待的那种状态可能对公司目前来说反而不省钱。这个省不省得从很多角度来综合看的，不只是表面花钱多少的问题。

也许我说得很虚、空洞无物，其实我只是想说站在不同位置上看到的光景可能大不相同。提建议是好，你可以先提，但不要引入情绪。如果对方不接纳，你可以慢慢多了解下对方的考虑点在哪里，对自己是个不错的提升。其实这点是在教育我自己，我也是个不吐不快的脾气货，我得经常提醒自己。

8楼 @nickel 我的意思是，因为用的是 AWS，其实完全是可以一个项目，一个VPC（虚拟云)，然后针对不同的虚拟云有不同的 security policy；有些项目可以紧一些，有些项目可以松一些，不需要一刀切。甚至所有项目都可公用一个VPC，但是分布在不同子网，然后针对不同子网有不同的 Security Policy。

但是，以现在的设计，是所有项目共用一个 VPC(虚拟云)，只有有限的子网。所以都一刀切了。

因为 Operations 跟 Security Architect 是以一个横向的角度去看公司不同项目的部署的，他们更希望有一个标准化的东西，而不是（至少是还没有）针对每个项目区做优化。

@minddriven 我理解Operation的态度，所有Operation都是这样看的，都希望以一个横向去一致化处理，而不是每个项目纵向管理，对于他们来说简单容易管理。而且除了你所在的项目外，其他项目听你讲的似乎也是能满足他们横向标准化管理的需求的，这就更难因为一个新的单一项目要求他们进行改变，他们缺乏这个改变的动力。换个身份去看就能理解了，除非你能动用上层力量，或者你帮助他们做一套便于垂直管理的工具，否则他们自身是没有动力去改变的，就算花钱那也是公司的事不是他们的事。一个公司大了，这种以屁股决定思维的情况太常见了。

4楼 @coredump 要是老外还真就不一样了. 国人就会中枪. 躺着也能中.

10楼 @nickel @minddriven 而且就是求稳. 求简单. 就一样的流程 脚本才好. 运维为了稳.

11楼 @cnsoft 从我的经历来看这大部分是个人不自信造成的错觉

当有不同的 team 一起协作的时候，每个 team 都有自己的出发点。从我个人角度出发，能够想到一个最好的 solution；不代表这个 solution 就是其他 team 喜欢的。

很多时候就是一个折中，所以我的 bottom line 是：只要不影响自己 team 的 performance，大家也都接受这个 cost，i am fine with it。

ps, 我在国内工作也是这个态度。