1. 程式人生 > >別跟我說這很容易

別跟我說這很容易

rkhunter isam tput 定位 角色 現在 調優 java rootkit

早上剛上班,接到了小王同學的電話,電話裏小王說自己辭職了,看看身邊有沒有合適的工作給推薦一下,我隨即問怎麽突然就辭職了呢,小王嘆了一口氣,說在這家公司幹不下去了。

小王所在的是一家中小型軟件公司,主要給客戶做項目為主,而小王是一線開發團隊的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 實現海量日誌采集、過濾、解析、輸出

別跟我說這很容易