早上剛上班，接到了小王同學的電話，電話裏小王說自己辭職了，看看身邊有沒有合適的工作給推薦一下，我隨即問怎麼突然就辭職了呢，小王嘆了一口氣，說在這家公司幹不下去了。
小王所在的是一家中小型軟件公司，主要給客戶做項目爲主，而小王是一線開發團隊的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海量可視化日誌分析系統》點擊前往
ps：【51CTO訂閱專欄】安卓小程序端，訂閱更優惠￥12
能學到什麼技能
1、結合企業真實項目需求，分析ELK架構的應用場景和價值
2、動手實戰構建ELK 海量日誌分析平臺
3、利用Logstash實時採集不同項目系統的海量信息，對海量數據進行過濾和解析，同時可以自定義匹配模式解析項目中的複雜結構日誌，並按日誌類別和日期回滾輸出到ElasticSearch集羣建立索引
4、利用Kibana 實現海量日誌的分析查詢、數據可視化及監控預警 。
5、Logstash核心配置語法以及Filebeat組件的靈活使用
6、Logstash Input插件、Filter插件、Output插件應用詳解
7、實戰：Logstash 實現海量日誌採集、過濾、解析、輸出