首先說下這個很難的技術定義，個人認為在你知道之外的知識都是很難的，一旦你深入瞭解其使用方式，原理，甚至閱讀了他的原始碼，你會覺得有的時候會恍然大悟。程式設計師是一個不斷要學習的崗位，就要面臨很多從未知到已知技術的時候，每當遇到這樣的情況時候，總有種不解決了這個問題，睡不著覺的感覺，心裡不踏實，總是想盡各種辦法去解決這個問題。甚至可以一直追查這個問題。也許這就是一種執拗吧

昨天剛領一個線上P0級重大事故，持續時間1小時，影響範圍全站！準確的時間點是下午17點開始，具體問題定位且聽我下文細細道來。

先說感覺，那感覺真是太刺激了，本來下午五點，昏昏沉沉的，瞬間一個激靈就清醒了（想象一下高中課堂，你在打瞌睡，突然老師走到你面前給你一下子的感覺），原本準備再過一小時吃晚飯了，吃完晚飯再摸魚到21點就可以下班了呀，別問我為啥到21點，問你就不是程式設計師！

帶著無比緊張且顫抖的心情開始定位問題，先來個錯誤日誌嚐嚐鮮：

1、下午五點開始有少量的慢sql報警，沒有人當回事，因為這種事情總髮生，雖然大家都知道在實際開發中如何避免慢sql，但是整個團隊要想完全避免慢sql卻很難；

2、五點十分左右，開始零星有使用者反饋指定功能不可用，SLB開始報警，技術開始介入排查；

3、十五分左右，客服部門電話開始爆炸，使用者密集反饋指定功能不可用，技術部開始重視；

4、二十分左右，所有服務大面積出現介面無法響應，整體服務不可用；

5、我們一開始定位覺得是MySQL的問題，因為前面有mycat的慢SQL報警，後來定位並不是MySQL，因為MySQL的記憶體、連線數、流量這些指標都很平穩；

6、最終在五點三十分的時候我們定位到是ES出問題了，因為所有的Java服務不可用最終都指向上面的錯誤日誌，dubbo提供的服務執行緒池滿了，再有請求進來直接拒絕了，檢視這個服務的程式碼，最終查詢的是ES，此時的ES程序已經處於假死狀態。

那接下來大家說怎麼辦？如何快速的恢復線上服務？

重啟！

是的，只有重啟大法此時是最快的解決辦法，你不可能說保留ES事故現場，讓我用arthas之類的工具來現場分析jvm記憶體情況。

然而重啟之後服務依舊是不可用，介面還是無法響應，大家知道這個時候是什麼原因嗎？為什麼重啟了ES服務還是不行？

後續繼續重啟報錯dubbo日誌的相應服務，當這些服務全部重啟完畢後，我們的服務終於恢復訪問了，這個過程持續了十幾分鍾，確切的說，直到17點五十多分，我們的所有服務才恢復了訪問。

接下來就是事故總結、相關責任人、產生問題的原因、接下來的最佳化方案，全公司郵件通報！

你說這個難不難？本身並不難，難的是事情緊急且重要，這個時候你慌了啊，亂手亂腳的，大家你一言我一語的，如何冷靜提取有效資訊然後儘可能快的解決生產的重大故障才是最難的！

最後，當一切都恢復平靜的時候，你會發現：“臥槽，好累啊！”。

虛脫的感覺！

最後祝大家程式設計師節日快樂，今年可是程式設計師的本命年哦～

2020 = 1024 + 996 = 404 + 404 + 404 + 404

這種感覺能難受，很壓抑。

技術難題，對於程式設計師來說，是經常有的事，關鍵是如何面對吧。

說下我的事情，雖然也會寫點程式碼，但並不是以此為正業，所以對於真正的程式設計師來說，可能說法會有點偏頗。

遇到難題時，一般都在網上搜索解決方法，一般來說，都有很優秀的程式設計師分享他的勞動成果，所以一般都能解決問題。但也真正碰到難的問題，一個就是迴圈的問題，無限極選單問題，當時都是找了很久，看了很多遍才明白過來，當時自己是幾天都不太開心，也不太想說話，總是在測試著程式。挺煩也挺不開心的。只是最後做出來了，心情就好多了。

這是我的一些經歷，當然，如果全職程式設計師，可能壓力就更大了。

作為一個天天划水摸魚的搬磚技術人員，感覺在專案中技術難題分兩種吧，

第一種是需要去實現很麻煩的功能。

第二種就是日常中碰見的各種bug。

最頭疼可能就是專案中突然有bug了，又碰見的是那種不是很明顯的語法錯誤，找了半天也沒有找到，我感覺這也是屬於種技術難題，怎麼去梳理迅速的找到問題解決問題。

如何形容這種感覺呢？焦躁，緊張，失落，無助，亞歷山大...

再多詞可能都描述不清楚。本人在工作中經常遇到難題，有些問題一兩個月都搞不定。遇到這種問題，估計只有下面這張圖的表情能描述此時此刻的心態了。

程式設計師遇到的難題其實分為兩種，一種是沒有辦法定位清除的問題，另外一種是定位清除了，但是沒辦法，或者很難解決的問題。

所謂難定位的問題，其實就是你根本不知道這個問題是什麼。比如系統突然掛掉了，你從現有的資訊根本不能確定問題在哪。這個時候你剩下的可能只有滿腦子的問號了。

如果系統只掛了一次，後面不再出問題，那就很難找出問題的根源了。不過這樣也有好處，那就是問題的影響的程度相對較輕，畢竟不容易出現。所以在軟體開發中通常不是什麼問題都解決的，因為不是所有問題都能搞清楚是什麼問題，談何解決呢！

當然，從技術層面來說並不是完全解決不掉。只是如果要解決需要涉及架構調整或者其它方面的改動，修改調整的內容太多。這種情況下就要考慮利弊得失了。

如果改動太大，可能會引入很多新的問題，可能得不償失。因此，遇到此類問題可能會採取一些規避方案。

當然，在開發和運營當中遇到各種問題是很正常的，關鍵是遇到不同的問題採用不同的策略。首先保證的是業務的正常執行，然後是考慮是否需要徹底解決。這樣慢慢調整，心理壓力會小一些。

作為一個工作多年的老碼農，在工作也遇到過一些艱難的技術問題，就以切身體會談談對這個問題的看法。

首先需要明確一下，問題是否困難除了取決於問題本身之外，還在於解決問題的人的水平，也許對你很難的問題，在別人看來不過是小菜一碟。明白了這一點，那麼這些技術問題也就成了考察程式設計師水平的試金石，有些人可能會因此氣餒，甚至放棄；而有些人則透過解決問題學到了很多新的技術，也讓自己進一步成長。

記得多年前看工作中要用到一款開源庫，那時候剛學完C++不久，自以為對面向物件瞭解甚深，然而學習這個庫時卻是一頭霧水，最後在經過泡論壇，然後又認真的學習了面向物件設計模式，後來不但能使用那個庫，更重要的是對面向物件程式設計有了更深的認識！

後來還有很多類似的事情，剛開始時感覺無比困難，但是透過自己的努力，或求助他人、或查閱資料，當最終問題解決時，你會發現自己又牛逼了一些，然後再遇到一些新的問題，如此迴圈……

其實程式設計也是一個學習的過程，就如同爬山一樣，每一階段都會有一些山頭，只有當你爬上山頭才能欣賞美麗的風景，但是當你爬上一座山頭的時候，就會發現更高山峰！只有當你爬上最高峰，才能“一覽眾山小”，可是到那時，你可能會嚮往地球之外的天地！

作為20年工作經驗的IT老兵，談談我的看法。

程式設計師遇到問題，這一般不屬於太緊急問題，我認為都還好說。

但作為生產系統專案的負責人，遇到難題就不一樣了。

作為這個專案的負責人，你需要了解硬體，網路，軟體系統，專案系統的編碼等等。因為這些都可能稍有不慎，就造成業務系統不能正常運營。

這種情況在我身上就發生過，我服務的是一個全國業務的金融服務機構。事情是這樣的：

一直執行很好，且沒有做過任何改動的系統，突然有一天被爆：某業務多次錄單，系統總是不能成功出單！

要知道不能成功出單，很可能會損失很多的業務！影響公司，業務，部門，個人業績！

要不說這壞事傳播的速度可真快！業務很快找業務領導反應，訊息很快就到了高管層，很快就到了IT，很快就到了我這裡。最關鍵的不是訊息到達了我這裡，而是各個領導一時間像審問一樣聚集到了你的工位！

於是飛舞著鍵盤逐項的排查，沒有收到任何預製的系統報警，所有的排查開始重新手工進行，頭腦飛速的旋轉著，手指敲擊到的已經不能再快，黑屏在眼前飛速的滾動……

更重要的不是這些，領導還在你耳邊不停的問這問那，你還必須順著他的思路去回答：有人修改過程式碼嗎？有人改過……？昨天還好，今天怎麼就出問題了？……

你要知道，出了問題是有責任負責制的，總會找出這個事情的最終負責人，所以我忐忑，我的直屬領導更忐忑。

耳邊不停的叨叨，這時你還不能顯出慌張，更要相信自己的能力！雖頭腦飛轉，雖手指飛舞，仍然鎮定自若的去響應領導的問題，以示自己的思路清晰，能快速排查出問題。

硬體，軟體，網路，系統，功能……排查，最終定位在該段功能的程式碼編寫上。問題是這段程式程式碼一直沒有變更，突然好好的系統卻一下子不好使了！

不過範圍縮小到功能層面，也算是好排查多了，逐行分析程式碼嘛，迅速召集程式設計師分頭行動：瞭解業務輸入情景，模擬系統的執行情況，一次不行，就再瞭解情況，再問，再試……

與此同時，領導還在一遍一遍的盤問有沒有這種情況？有沒有那種情況？是不是這個問題？是不是那個問題？

還好，功夫不負有心人，原因在專案成員的快速行動與努力下終於找出來了：程式程式碼考慮不全面，功能執行時間超過了3秒鐘，導致了該業務的熔斷……

哦～～～ 總算送了一口氣，就像從一場驚心動魄的噩夢中醒來。

很難的技術問題，這種一般要看是在什麼場景下遇到的，比如之前在公司生產環境上遇到過一個redis反序列化，第一感覺就是很奇怪，當時已知的資訊是：報錯是偶現的，過一會就好了。

由於是偶然出現的，並且當天也沒有釋出，初步斷定先不著急回滾，先定位原因再說。

因為偶爾出現，首先看了報異常那塊業務邏輯是不是有問題，花費1個小時前後看了一遍也發現什麼問題。

看了下對應日誌，發現是在Redis讀超時之後才出現的該異常，因此懷疑redis client操作邏輯那塊導致的（公司架構組對redis做了一層封裝），發現獲取/釋放redis連線程式碼有問題。

初步定位原因是：發生了讀寫超時的連線，直接歸還給連線池，下次使用該連線時讀取到了上一次Redis返回的資料。因此趕緊本地驗證下，最後發現確實是這個原因。

確認了原因之後，當天就修復了，從發現到最後修復，花費了半天時間。從最初分析錯誤日誌認為是程式碼原因、到認為可能是資料序列化協議使用姿勢問題（公司序列化協議使用了hessian）、到最後分析錯誤認為是redis封裝使用問題，過程中伴隨著驗證，一步步深入問題的本質，最後解決問題，對自己印象很深刻。

前提是技術問題：

我一般會經歷以下幾個階段

1、很興奮：我去，碰到個不會的，意味著什麼，又可以get新技能了。然後開始分析問題，試著去解決。結果一頓操作猛如虎，程式原步踏地走。

2、開始認真：到網上各種查材料，問別人，到最後的可能的結果是，一千個哈姆雷特就有一千個答案，還沒有一個適合你。

3、很沮喪：開始找外在原因，重啟軟體，重啟系統，試著碰運氣。

4、很暴躁：於是選擇把問題交給時間。

第二天再次嘗試，發現很神奇的好了，自己並沒有動過什麼。於是才意識到，程式是有自己的思想的，人類能夠做的只是瞭解他，理解他給他自由的空間，他才能還你一個驚喜；

什麼樣的技術問題是很難的問題？這要因人而異，每個程式設計師的技術水平、學歷和工作經歷以及知識積累都各不相同，所遇到的困難也各不相同。很簡單的一個技術問題，對沒掌握這個技術的程式設計師來說，他就覺得這是個很難的技術問題，但是對有豐富經驗的程式設計師來說根本就不是什麼技術難題，在程式設計師的生涯中，會面對著各種各樣的技術問題， 如果沒有遇到技術難題，你的知識技能工作經驗就不會得到提升，遇到技術問題，勇敢面對，積極去解決問題，積累經驗，為以後的職業生涯中知識積累

工作快20年了，我是做網路安全開發的，遇到印象最深刻的難題是有一次疑似我們的產品導致客戶那裡OA，郵件等等業務在某天凌晨全體宕機，由於凌晨出現的問題沒有人發現，第二天客戶那裡業務全癱瘓了，被客戶列為嚴重事故。當時的現象特別詭異，所有的windows伺服器集體黑屏，可以ping通，但遠端連線就是黑屏，無法操作，部分業務無法工作，但有一些似乎還在工作，當抵達現場時故障現場已經被重啟進行了恢復，由於客戶認定是我們產品的問題，客戶的現場工作人員極度不配合，我們最初連日誌都拿不到，當時真的是亞歷山大。

當時的感覺真是一言難盡，自行腦補當時的情況吧。

這個很難的技術問題太籠統了。如果是公司做專案，應該不至於一頭霧水，因為專案技術選型肯定要確定哪些技術，一般公司沒接觸過的不會太去選，這種的可以請教公司同事。還有就是技術選型時確定的新技術沒接觸過，這個肯定是要給時間去學習的。最後就是個人遇見的，這種只能花時間去學習琢磨，焦慮也不能讓你會這個技術。

看是什麼問題了，有問題就有工作，有工資，有月底獎金。

特別喜歡問題被解決時候的成就感，別的同事看到我仰望的神態。

技術嘛沉下心來，慢慢搞，不要急，總能解決的

慌，慌得很。

任何技術水平的人遇到難以解決的問題時都不好受。區別在於難受多久和最後解決問題的決心。是對人心理狀態的一個不大不小的考驗。

內心強大的人，在懵圈片刻後，會穩定情緒並下定決心研究並解決問題。

內心弱小的人通常會選擇放棄，踢皮球亦或自暴自棄。

解決問題的能力最終取決於解決問題的決心。

程式設計師的一生彷彿都在生產bug到解決bug再生產bug又解決bug，猶如“生死輪迴”，但是程式設計師們遇到超難的bug和技術難題的時候，假如我沒有猜錯的話，都是一個感覺，“生不如死”。不信你們看下面的這些表情，你是否存在？

遇到技術難題，不說話表示不會，但是不問程式設計師就是那麼強脾氣。這個大多數程式設計師都有的通病，遇到難題的第一時間是埋頭尋找答案，從百度搜索到查詢開原始碼，可謂36計計計擦邊而過，不說話的預設不會的的思考方式就是和問題死磕到底。

嘗試過多種方式後，還是行不通，原本頭髮就很稀少的程式設計師也會瘋狂的抓頭髮，抱頭苦惱中，n多種方式都嘗試了bug依舊，但是都沒有重頭開始的勇氣和換框架或者是外掛的決心，常常帶著問題睡覺，然後第二天重新開啟電腦又是信心滿滿的面對bug，一方周旋後bug都是視你為初戀，失敗而告終的通只有程式設計師知道。

經歷了幾天也努力也沒有解決難題，只能向同事，領導尋求幫忙，困擾了幾天的bug在別人面前兩個分鐘的事情，就是那麼的不堪一擊。在問題解決的瞬間，那種感覺就像是重生，而沒有解決前的那時候就是“生不如死”。

總之bug和程式設計師是勢不兩立的關係，總有人歡喜有人憂。

很難解決一般就是遇到某些瓶頸了，不同瓶頸的感覺是不一樣的，但無非可以歸結為下面幾類。成本原因不讓馬兒吃草，還想讓馬跑。這個是有些不太理解網際網路的一些領導的錯誤觀念，他們會給你安排一個老舊桌上型電腦，想要讓你承載幾萬、幾十萬併發的秒殺系統，你當然很難解決。外界的評論可能是，“這幫程式設計師是吃乾飯的麼？這系統也太垃圾了！”老闆的評論是，“我這桌上型電腦也不少錢呢。”程式設計師的評論是，“這摳門老闆不會是個傻子吧。哎，再最佳化最佳化吧。”當然，有些情況也是能夠理解的，公司明白需要更好的裝置，但是由於成本控制，不得不在某些方面節省。但換句話說，裝置成本是佔不了一個大頭的，可能有其他方面的成本更加需要收緊。如果是因為成本原因，我們的心情可能是無奈，又有些不能施展拳腳的束縛感。

歷史原因舉個例子，系統用了5年了，迭代了N個版本，在面對新的需求的時候，就會出現需求限制於系統的情況，常常會有程式設計師說，這個實現不了，那個不符合現在系統規則。其中很大一部分是這些年的積累，欠下的技術債造成的。俗話說，大船難調頭。這種情況更多的出現在剛創業之後的幾年，由於一開始的快速迭代，追求先把業務流程跑通，先生存再規範，會讓一開始的軟體開發流程並不那麼規範，如果在1-2年內沒有進行重構，那麼積攢的3-5年的技術債就會慢慢把你壓得喘不過氣來。解決這種情況，一是需要時機，給出足夠的空間和時間讓技術團隊重構，二是需要魄力，你得有成功的把握，不能幹著幹著說不行了，咱們還是回到原來吧。如果是因為歷史原因，我們的心情可能是期待和渴望，又有些對現狀的無奈。

能力原因雖然說專家很厲害，但說白了，大部分企業需要的研發人員，還到不了需要專家的級別。所以，一般而言，沒有什麼技術是攻克不了的。如果真的遇上了，那就說明你的公司已經到達了一個新的層次，從而需要那個層次的人員來解決，可以透過外聘或者顧問的方式，引進新的技術。如果是因為能力原因，我們的心情雖然有些力不從心，但又為公司在新的臺階而高興。

不管怎樣，程式設計師是一群追求美好的人，不管是外部限制還是內部限制，不能解決的難題對於技術人員來說總是很憋屈的。

說一說自己的感覺吧，有時接到領導分配的很難的技術問題，自己以前也沒做過，周圍也沒人懂，網上也找不到相關程式碼，但很快又要彙報結果給領導，每日加班到很晚還是沒有解決問題，那種壓力、焦慮和難受是比較難忍受的，頭髮也掉得厲害，很無助也很無奈，真是不堪回首。

您如果也遇到這種很難的技術問題，可以到網上論壇發貼求助，如csdn論壇、水木bbs等，可能會有人可以解決您的問題；另外您也可以和領導說明您的難處，協商尋求其它解決方法，如外包求助、增加人手一起來解決等，畢竟一個人的力量是有限的，這時團隊的力量或許會有幫助。最後，程式設計師也有家人要照顧，也有其它很多事情要處理，如果覺得壓力大，身體、心理方面負擔重等，適應不了這份工作，可以考慮換崗位或工作。

先來說說我的感受吧，如要交待你一項任務，在規定的時間內要完成，但在這中間遇到了你搞不定的問題，連你周邊的同事一時都搞不定怎麼辦呢？

1、先跟據的問題，詳細檢查全部業務邏輯程式碼和各種配置檔案，看看有沒有遺忘問題在裡面，還有就是有沒有其他可替代的解決方法，自己有沒有嘗試其他解決辦法等。

2、將相關問題，先google一下，看看有沒有類似人問相關問題，下面有沒有解決方法等，如果有當然最好，如果沒有看看別人有沒有提關解決問題的意見和思路，再對比一下你自己的開發環境，看看是否能找到突破口，這一步非常關鍵，考驗你解決問題和分析的能力。

3、如果在上面一點後還沒有解決，那你就要找一些相關技術很強的技術論壇及技術交流群，把你遇到的問題詳細的羅列出來，等待大神的回答。比如我之前遇到vmware的相關問題，釋出到VmSky論壇，第二天就找到答案了。

4、在經歷了上面三種方法後，還是沒有能搞定，那就需要跟專案直官領導彙報問題，商量一下該怎麼辦。後續的事情你應該懂得了。

我是【不愛八阿哥】，一個地地道道的程式設計師，大學學的計算機專業，畢業後從事程式開發，對於這個問題深有體會。

首先說程式設計師是什麼，程式設計師是一個矛盾體，是一個創造問題並解決問題的人，所以說程式設計師在工作中每天都是在解決問題併產生新的問題，如果說一個程式設計師在開發中沒有遇到過任何問題，那麼他一定不是一個合格的程式設計師。

程式設計師遇到很難的技術問題是一種什麼感覺，這個問題要分開說，如果我是剛入職一兩年，我遇到一個很難的問題，也許會有些慌亂尤其是這個問題關係整個專案的進度的時候，如果放到現在，我可能會很興奮，不論這個專案是否關係的專案的進度，我都會很興奮的（現在都有點兒變態了），因為作為一個從事開發多年的程式設計師來說，解決完問題的那種成就感才是最爽的，如果每天總是再解決CRUD的小bug，慢慢的就會變得無趣的，生活和工作需要一些問題，只有這樣才能是自己得到鍛鍊！

上面說了遇到問題的兩種心態變化，現在說說如何解決問題吧，畢竟這才是我們應該考慮的問題，逃避是沒有用的，首先如果作為一個剛入行不久的人來說，遇到的問題應該都算不上簡單，因為畢竟書本上學到和實際還是有差距的，這時我們應該求助同事或度娘，現在網路如此發達想要找個解決方案還是能搜到的。

其次如果你是一個已經入行很久的老人了，那麼我覺得應該會先從分析問題開始吧，為什麼會遇到這個問題，只有分析出原因才能找到解決問題額辦法，同時應該考慮最優解的問題了！

1.相關的專業網站查詢資料；如果沒有找到答案會倍感壓力；這種壓力是質疑自己技術生涯是不是還有待提高！

2.請教更加厲害技術人員，還沒有答案，就會覺得自己隨時會失業。

當透過各種途徑解決了問題，感覺真個人都輕鬆多了。