别跟我说这很容易

Posted 2021-01-11

早上刚上班，接到了小王同学的电话，电话里小王说自己辞职了，看看身边有没有合适的工作给推荐一下，我随即问怎么突然就辞职了呢，小王叹了一口气，说在这家公司干不下去了。

小王所在的是一家中小型软件公司，主要给客户做项目为主，而小王是一线开发团队的leader，平时上班沉默寡言，基本可以理解为“逆来顺受“型程序员，是个典型的IT男，按照他的说法：要还房贷、车贷、上有老、下有小，因此工作上任何不顺心的事都可以忍受，什么都可以丢，工作不能丢。但是这次，他忍不了了。

什么原因呢，这要从最近的一个项目说起:

销售接到客户的一个需求，要做一款单位内部使用的通讯APP，功能需求类似与微信或QQ，销售一听，觉得这个功能很熟悉，应该很好实现，一口就答应了，然后销售就给小王所在的项目经理提出了开发需求，要求小王带队一周内开发一个带有用户互动功能的APP。

小王接到开发需求后，跟项目经理进行了技术评估，项目经理的意见是，这个通讯APP要实现的功能是个烂大街的技术，很容易实现，想都没想，就接下了这个活。

但小王拒绝了项目经理，他说这个通讯APP开发周期太短，又没有类似技术积累，一周内绝对不可能开发完成。而项目经理表示完全有可能，他拿出专业的姿态，告诉小王说网上有现成的，下载下来改改就行了。而小王对此方案果断拒绝，原因是：网上下载不到完全适合客户需求的，就算有，下载下来也要经过一段时间的代码熟悉过程。

经过小王和项目经理、销售的多方激烈研讨，没有任何结果，最后，销售拿出了杀手锏：项目已定，客户要的急，必须在一周内开发完成并给客户演示，否则，会影响项目收款，甚至，这个项目就黄了。

将开发需求上升到项目黄的地步，作为技术人员来说已经基本无还手之力了，只能忍气吞声，硬着头皮上了。

作为开发团队的骨干，小王的做事风格是，要么不做，要做就一定做好，小王从其他公司把他一个专门开发APP的好友请了过来做外援，并向部门领导申请一定数额的兼职费用，同时，由于时间短、工期紧，小王提出这一周内员工加班要支付加班工资。

这里又一个矛盾出现了，加班可以，要支付加班费那就万万不行了，经过领导和项目经理的又一顿秘密协商，给出了两个结论：

（1）、加班可以，加班费是没有的，原因是因为这是公司的常规项目赶工，属正常范畴。
（2）、外援给兼职工资可以，但是只能给小王提出的一半，没得商量。

小王听到这个结果，大为恼火，跟项目经理又是一阵争锋相对，此时，项目经理也火了，他告诉小王：技术没有你想的这么值钱，况且这个APP的功能很容易实现，换了其他人网上扒拉点代码改改就可以了，也许不要七天就可以完成。

销售经理语重心长的劝解小王说：他请来的外援能给一半工资已经很不错了，别老把技术抬的这么高，这个客户的需求真的很简单，很容易实现，辛苦一下就搞定了，为这点小事大动肝火，真没啥必要！

好吧，都这样了，小王还能说啥，以他的开发经验，一周内要将稳定的产品交付给客户是肯定完成不了的工作，既然做不到，那就不做了，当天，小王就向公司提交了辞职报告，晚上，他在朋友圈写下让我敬佩的签名：别对技术人员说这很容易实现。

小王的故事，相信每个做开发人员都经历过，这件事让我想起我多年前做项目时候的一个故事：

大概在5年前，我所在的是一个给客户做网站平台的项目公司，我的角色是网站系统开发人员，每个项目开始之前都会进行投标，在一个客户的投标现场，投的是一个综合性网站业务系统，用户预算30万，我们报价36万，然后等待客户砍价。

事先客户告诉我，最后中标价估计在25万左右，根据预算，以及砍价的额度，我们觉得报价36万是很正常的。

在招标会开始后，意外的一幕发生了，招标的一个年轻评委突然发话：他说这些网站没有任何技术含量，网上很多免费系统可以直接拿来使用，并表示，现在这个年头做网站的已经一抓一大把了，有的公司两千块都能做一个网站。以你们这个系统的技术难度以及工作量，顶多10万元。

作为有技术追求的我，立刻被他说的话激怒了，我马上反驳道：网站开发的工作量有很多，有很多定制开发模块，并且有多个功能实现难点和技术难度以及多少个非常好用、领先的功能，但不管我费尽口舌，百般解释，评委依然认为这个网站没有技术难度，很容易实现，根本不值36万。

最后，在持续了一个多小时的僵持下，我们被迫承认“技术很容易实现”，15万成交了，这个妥协是项目经理最后定下来的，因为如果不降价，项目就会流标，这个项目也跟了很久了，此项目之前做的工作都会前功尽弃。

招标结束，各个厂商、评委开始夸夸其谈起来，之前那个年轻评委跑过来，给我递了根烟，诡异的一笑说：“哈哈，我说的吧。他们这些软件公司啊，总是想多赚点，事情少做点，把技术难度哄抬的这么高，其实有什么啊？烂大街的技术，不就是拼凑了事么，我见多了”。

说真的，当时我真想揍他一顿。不过从这次事件之后，我再也不参加类似的招标会议了。

是的，技术上有时候是需要妥协的，但是，做技术这么多年，我遇到更多的是下面的情况：

我之前的一个客户，一天突然给我打电话，神色恍惚，说他们的erp系统故障了，导致业务全部中断，非常着急，他们请了很多人，包括厂商，都没有彻底解决，打电话想寻求帮助，看看能不能协助解决，接到客户的电话，我马上赶到现场，了解了故障的前因后果，经过2个多小时定位，终于发现了问题，在忙碌了三个小时后，搞定了客户的问题，客户对于我的帮助非常感动，给我所在的公司发来了感谢函，并确定了长期的合作关系，而我也因为此事，在公司升值、加薪。

我想，这才是技术的力量，技术的魅力。

技术是一门艺术，博大精深，但是对不懂技术的人，请不要随意说这很容易实现，那也很容易实现。因为，这会伤了技术人的心。

技术彩蛋

～～～～～～～～～～～～～～～～～～～～～～～～～～～
说了这么多，那么问题来了，怎么获取经验和能力呢，我将多年来工作经验进行了总结和提炼，写成了专栏《Linux运维大牛实战心法》 点击前往，15个案例打通运维任通二脉，让案例说话：

能学到什么技能

第一部分：故障排查
1.Linux系统故障问题案例汇总（无法启动、忘记密码、丢失文件等）
2.偶遇"Too many open files"错误分析与处理实录
3.Linux遭遇"Read-only file system"错误分析与处理实录
4.不听话的Crontab，记一次Crontab计划任务失败案例
5.因OpenStack物理机故障引起的Linux系统无法启动案例
6.Linux系统内存又被吃光了，它去哪里了，记一次内存占用问题调查记

第二部分：系统安全
7.回顾与总结：服务器遭受攻 击后的处理措施
8.IDC服务器遭遇黑 客侵入后的解决方法与原因分析案例
9.Linux后门入 侵检测工具chkrootkit、RKHunter应用案例
10.云服务器被植入挖矿病毒的处理与原因分析案例

第三部分：性能调优
11.菜鸟运维初成长，记一次上线Linux服务器基础优化案例
12.对某电商平台动、静态网站的优化分析案例

第四部分：运维案例
13.远离mysql的MyISAM，记一次MySQL数据库故障的处理与原因分析
14.一次Java应用OutOfMemoryError故障的处理与原因分析
15.一次Java进程占用CPU过高问题的排查方法与案例分析

～～～～～～～～～～～～～～～～～～～～～～～～～～～

如果你对大数据方向的技术干兴趣，那么也可以阅读我的ELK专栏，我将多年来在新浪网和阿里云担任系统架构师的经验，融合进51CTO订阅专栏《轻松玩转ELK海量可视化日志分析系统》点击前往

能学到什么技能

1、结合企业真实项目需求，分析ELK架构的应用场景和价值
2、动手实战构建ELK 海量日志分析平台
3、利用Logstash实时采集不同项目系统的海量信息，对海量数据进行过滤和解析，同时可以自定义匹配模式解析项目中的复杂结构日志，并按日志类别和日期回滚输出到ElasticSearch集群建立索引
4、利用Kibana 实现海量日志的分析查询、数据可视化及监控预警 。
5、Logstash核心配置语法以及Filebeat组件的灵活使用
6、Logstash Input插件、Filter插件、Output插件应用详解
7、实战：Logstash 实现海量日志采集、过滤、解析、输出