这个时代，尤其是coder领域，想要做好一件产品，已经不是个人英雄主义的舞台了，因为一个产品涉及的软件栈太复杂了，比如你做的是PAAS，你以为就不用关注IAAS了吗，对不起，理想很丰满，现实很骨感，理想与现实总是存在很大的差距。
理想是基于一种假设，假设IAAS永远不会出问题，那么PAAS就完全不用关心IAAS，假设PAAS永远不会出问题，那么SAAS就完全不用关心PAAS，试问可能吗，就像经济学的开篇，假设人都是理性人一样。
没有依赖，就没有伤害，只要有依赖，就会有伤害。
除非你牛逼，全栈代码撸一遍，还要自己建工作站。那还得牛逼的一塌糊涂，写出来code永远不会出问题。
笔者虽处的领域的是云计算三大基石之一，但实际上做的业务属于PAAS，那么肯定依赖IAAS咯，比如VM，比如块存储。最近遇到几个问题，就分别有ECS和EVS。
我拿着问题满怀喜悦的去请教他们，和ECS的一个同事“交流”了很久，最后说你重新创建吧，我“据理力争”说如果站在用户的角度考虑，这用户体验也忒差了吧，然后那位同事有说线上环境比较好，这么低概率的事情基本不会发生(默念三遍墨菲定律)，最后丢了一句——我也想解决问题啊，但是还得找xxx一大堆人，难啊。然后，就没有然后了，这事儿就这么了了。
昨天线上cn-south遇到一个问题，我们这边由于失误同时对同一个vm挂载同一个卷连续下发了两次请求，而挂载这个动作是异步的，我们下发挂载请求后，会在listen中不断的查询这个job的执行状态，仅有的日志中却只看到了一个jobId，理论上说连续下发两次应该有两个jobId，但是目前来说，实际情况得不到验证，一是我们没有打印日志，正常情况很少打日志，二是我们想得到EVS的验证，无奈他们不配合。。。我又一次满怀喜悦的拿着问题去请教他们(嗯，这次从他们的接口列表中找到了很多人)，想了解底层对于共享卷的挂载流程是怎样的，卷的状态是如何转换的，无奈，都是大咖，理都不理，发出去的求教石沉大海，只有一个SL和我“交流”了一番(真的要感谢你，只有你理我了，也算是对一个真心请教者的心里安慰了，不然会让哇凉哇凉的心更凉了)，最后也没能给我讲解，我都说了如果没有时间讲解可以丢一张流程图给我，真心的只是想了解一下，好让我们遇到的这个问题有个尽可能好的归宿。
突然发现，在我司内部找人(实际上可以用求人了)请教有个特色，如果不认识，或者没有熟人牵线，别人是很难理你的。
往坏处理解，那就是“各人自扫门前雪，莫管他人瓦上霜”，往好处理解，每个人都有自己的事情，没有义务去解答一个和自己本职工作完全不想干的问题，从绩效的角度考虑(涉及到这一块，人总是变得那样的现实)，自己的领导又看不到，总不能在第二天的晨会上说，昨天给一个xxx(一个大家都不知道的人)同事讲解了一下我们yyy模块的流程吧？！也可以理解，人们工作，都是为了吃更好的饭。
昨天小组吃过晚饭“走一圈”的时候，还聊到了如果在老家，办一点事儿都要找熟人，说在大城市好呀，不太用找熟人。现在我只想说一句，呵呵哒，那是不可能滴！！无论在哪里，只要生活在这片深爱的土地上，都是熟人好办事！
哦，扯远了。
一个人，仅凭一己之力，想做好一件事，难啊，难！
网友评论