作者：張榮華（六铢）
日期：2018-04-11
如果我問我們的客戶他們想要什麼，他們會告訴我他們需要一匹更快的馬。——汽車制造商先驅亨利·福特
與所見略同的人溝通，益處不大，要有分歧才有收獲。——史蒂芬·柯維
如何自底向上推導應用邏輯架構？
一、什麼是架構？
大概是在11年前左右，在洋芋網做廣告平台，同時也做視訊CDN的相關事情，當時做一個服務，基礎架構是lighttpd + squid + tomcat，将靜态資源分離到httpd，get請求使用squid緩存，智能路由使用HTTP post請求，并讓tomcat提供服務，當時就覺得這就是架構。再後來，做了視訊CDN相關的基礎建設的工作，就覺得這就是做架構，關鍵那個時候也沒有人告訴我們什麼架構，自己不知道自己不知道。
再後來慢慢成長，又去了做了幾年中間件（包括高性能RPC和JSR-170），然後就覺得這也是做架構。當時也沒有前輩跟我講什麼是架構，那個時候的我對架構是沒有體系化認知的，都是憑着感覺做的，是 不知道自己不知道
再後來，來到了阿裡做應用研發和架構了，發現業務開發中也包含了各種方法論，而以前也看過的模組化相關的資料，在中間件等基礎設施上有沒有太大的感覺，反而在業務技術領域發揮出了巨大的光芒。也發現越靠近使用者的地方的架構在随着企業的慢慢壯大會變的越來越重要。這個時候的我對架構認知是 知道自己不知道了
既然知道自己不知道了，那麼就是要追尋它，曾經我和不少業務的研發同學讨論過架構是什麼，撇去基礎設施架構和實體架構等視角不談（這些視角聊起來也是篇幅很長的），我挑應用邏輯架構并從幾個角度來嘗試描述一下：
1.從架構的總原則的角度：盡可能簡單（在目前場景下要盡可能簡單便于擴充和維護），但是不能太簡單（相對而言太過于簡單可能在場景上有所遺漏）
2.從架構的目的角度來考慮：既要解決過去的問題，也要解決現在的問題，還能适度解決未來的問題，這些問題既包含技術問題，更包含業務問題
3.從形态之2維的角度來考慮：架構就是橫的問題，和豎的問題。橫就是分層，豎就是分區，橫豎都有抽象的事情要做
4.從形态之3維的角度來考慮：架構是三維的，在x軸和y軸上有橫豎的問題，在z軸上還有粒度的問題
5.從時間軸的角度來考慮：架構不是一層不變的，是随着業務的發展在不斷變化的。
可以看出，雖然我試圖從以上幾個視角對架構進行了描述，但是顯然這些描述都是見仁見智的觀點，是從某個角度來看架構。從内心裡我自己覺得自己的這個提煉的高度是不夠的，從實踐中的總結必須和業界的知識結合起來，我必須學習前人已經總結的體系。于是在不斷的搜集資料的過程中，我發現在ISO/IEC 42010:20072中對架構有如下定義：
- 職責明确的子產品或者元件
- 元件直接的關聯關系非常明确
- 需要有限制和指導原則
這個架構的定義很簡練，很實在。小到一個玩具，大到一個國家的運作都可以隐含着這樣的内容。
但這是一個廣義上定義的架構，經過一些總結思考，我覺得實際上具體到我們日常的工作中，在不同的層次，會有更加精細化的架構分類。
二、架構有哪些分類?
在工作中我遇到不同的職位的人從不同的角度來描述架構，但是我們鮮有能達成共識，剛開始我也不知道為啥讨論不到一塊去，後來我經過一段時間的糾結和深入仔細的思考後，發現很多時候大家描述的架構都不是同一個角度的東西，于是我嘗試從如下幾個角度劃分架構的類别，以幫助我們在不同的場景和不同的人聊天時大家可以聚焦，明确我們到底是在讨論哪種架構，以提升溝通效率，并盡快達成共識，目前這個劃分已經在我們團隊基本達成共識。
值得注意的是，不管下面哪種分類的架構，都符合上一節總的架構的定義：子產品（元件）+ 關系 + 限制&原則。
産品功能架構 這個是産品經理最喜歡講的架構，一般來說，講我們有什麼功能的時候，産品功能架構描述的是能做什麼，閱聽人群體一般是使用産品的同學。如果我們做軟體設計時，不應該産出這玩意，而是應該産出應用邏輯架構和應用實體架構。但是一旦我們要對外宣講我們的産品，比如我們的接口有啥用，應該怎麼用，這個時候我們講的應該是産品功能架構。
目的：指導使用者使用産品，是以子產品的聚合是從使用者視角出發的
閱聽人：使用産品的人
包含的内容：闡述産品個功能子產品的能力：比如一輛汽車，方向盤有什麼功能，方向盤的按鈕上各區域的功能是什麼，儀表盤分成哪些功能子產品，每個功能子產品有什麼作用，油門踏闆有什麼作用，刹車踏闆有什麼作用。但是也不排除有些高階使用者需要明确知道變速箱的齒比等資訊，是以在産品功能架構圖上也可以描繪出來
命名：這裡命名需要考慮如何取一個吸引人的名字（同時又能表達産品的能力）來吸引我們的使用者前來使用，比如說以前經常有産品套用“納米”，又有産品套用“綠色”等等。
業務能力架構 用來分析業務，業務概念架構是指擁有哪些業務子產品，且各自的能力是什麼，這張圖有助于我們分析和了解業務需求，也有利于産品經理分析業務。是以業務概念架構和業務概念模型都是用在分析階段。
目的：研發人員和業務人員了解業務内在的概念和聯系
閱聽人：研發人員和業務人員，主要是給規劃業務的人使用
包含的内容：業務能力，能力中的子能力
應用邏輯架構 軟體設計本身，子產品，粒度，職責，複用，等等，在講解軟體設計的時候，使用的是這個架構圖，這個架構圖是通過系統模型和業務概念架構推導而來。是以系統模型和應用邏輯架構都是用在軟體設計階段。
目的：指導軟體的研發
閱聽人：研發人員，各層級架構師，各層級技術管理者
包含的内容：闡述架構中各子產品的職責：如系統模型，技術子產品，技術子產品的關系，技術子產品的核心抽象，如何用設計模式來讓架構符合軟體設計原則，等等。如果拿汽車舉例，那就是發動機子產品中包含了哪些子子產品（活塞，曲軸，連杆，缸體，缸蓋，等等）發動機子產品和變速箱子產品之間的關聯關系是什麼，如何協同工作，和底盤的關聯關系是什麼，如何協同工作。發動機，底盤，變速箱，電子系統在整輛汽車中的職責，關系，限制是什麼。這些都是用來指導汽車研發的。而不是指導使用者如何使用這輛汽車的。
命名：這裡的命名需要樸實無華，精準的描述出職責，華而不實反而讓技術的同學無法了解這到底是什麼玩意，導緻實施的時候職責放錯地方，挖下大坑讓後人來填。
應用實體（部署）架構 軟體部署時的架構，這張圖推導自應用邏輯架構，推導時重點邏輯架構如何落地，比如使用何種微服務容器，邏輯架構的子產品落地時應該是package，還是應用，也有可能是一組應用，是不是要跨機房部署，甚至跨國部署等等。還需要考慮穩定性，性能，成本等話題。
基礎設施架構 選擇什麼樣的中間件，存儲，監控，報警，等等之類和
三、能力和職責的差別
在日常的架構讨論中，有的同學經常談架構的能力，有的同學經常談架構的職責，那麼能力和職責有什麼差別？跟産品的同學打交道多了之後，發現産品同學很多都是講能力，後來技術的同學也開始講能力，而通常我們架構的同學原來講的都是職責，兩者有什麼差別呢，我說說自己的了解：
1.能力（産品功能子產品的能力）：是指一個産品能做什麼，比如中台本身是一個産品，對使用中台的同學來說，我們應該講中台的能力（其實是在講中台這個産品的能力）。是以講能力是講給架構的使用者或者其他想了解的人來聽的。
2.職責（邏輯架構中各子產品的職責）：是指架構内子產品的職責，用來指導開發，比如中台研發的同學，應該講架構的職責，依賴，限制。是以講職責是講給研發的同學，講給域内的架構師，講給域内的管理者來聽的，總的來說就是講給架構的實作者來說的。
簡單來說就是：能力是指産品的能力，職責是指架構内部的職責。如果架構本身也是一個産品需對外輸出（如中台，或者其他技術架構作為産品輸出），則對外輸出時，我們應該講這個技術産品的能力（這個時候技術的同學也就開始講能力了）。是以當我們讨論問題的時候，如果有的人在談産品能力，有人在談架構内部職責，那麼顯然已經不是在讨論同一個話題了，請大家務必注意區分這種情況，差之毫厘，謬以千裡，雞同鴨講啊。
比如說兩個子產品A和B，職責不一樣，但是依賴了相同的二方庫。那我們不能說某個職責在這個二方庫裡。這個二方庫作為某個獨立的技術小産品，提供了某些能力。但是履行職責的還是A子產品或者B子產品。
如何自頂向下建構架構？
一、問題的本質
我也在很多場合問過一個問題：什麼是問題？雖然我們天天挂在嘴邊，但是沒有人能夠給出較為合理的答複，之前我也沒有想過這個問題。而且很多人對問題的了解還不太一樣，一部分人認為問題就是方案中的難點，一部分認為問題是現實和目标的差距，這些解讀我覺得都還不夠精确，我在嘗試定義無果之後查詢了大量的資料，終于找到了一個比較合理的定義，目前我認為毛主席的解釋是比較合理的：
問題就是事物的沖突。哪裡有沒有解決的沖突，哪裡就有問題。 --毛澤東
而主管們經常問到：
1.你要解決的問題是什麼？
2.這裡的問題定義是什麼？
其實潛台詞在問，這裡事物間的沖突是什麼（已經發生的沖突，将來會發生的沖突，可能潛在會發生的沖突），這個沖突如果不早點解決，可能會激化，帶來很嚴重的後果。
其他例子
1.中國人日益增加的财富和國産商品的低劣品質就存在沖突，這個沖突就是個問題（已經發生的沖突）。是以我們要提倡中國質造。
2.如何利用新技術，更快更準的幫助消費者找到其最需要的商品，提升幸福感（将來會發生的沖突，在沖突發生之前，我們應該将之解決，在這個過程中，一堆友軍會被改造）。
上面幾個問題的定義都是社會級問題，而且都是公司層面在解決的問題，在我們技術同學的手頭的工作中應該也存在各種問題，比如說QPS太低，RT太高，不穩定，研發效率低，等等，這些問題的定義稍微常見一點，基本上大家隻要解決問題，而不用定義問題。
二、準确定義問題是成功的開始
這麼多年來筆者review過很多技術方案，而且也經曆混沌混亂的子產品設計，大部分糟糕的設計基本上是莫不清楚自己到底要解決什麼問題，總是覺得這個問題我要解決，那個問題我也要解決，甚至不是問題的問題我也要解決。然後設計出了一個能解決所有“問題”的方案。但是實際情況是有些問題根本不是問題，有些問題确實是問題但是卻又不是核心問題，有些問題是核心問題，但是又不是當下最核心的問題。我相信類似的方案有很多在review的時候被擋下了，但是還有很多應該已經上線了。如何盡可能減少這方面的損失？那就是要開始階段就要準确的定義問題，這也是這麼多思想家推崇問題定義的原因。
著名思想家杜威如是說道：
'A problem well-defined is a problem half solved.' - John Dewey
愛因斯坦如是說道：
提出一個問題往往比解決一個問題更重要，因為解決問題也許僅能是一個數學上或實驗室上的技能而已。而提出新的問題、新的可能性，從新的角度去看舊的問題，都需要有創造性的想象力，而且标志着科學的真正進步。 - by 愛因斯坦
那麼準确定義一個問題要考慮哪些次元呢？我粗粗的列了一個表格，隻是代表我自己的了解，未必是正确或者全面的，大家批判的閱讀：
主要問題 次要問題 緊急問題 不緊急問題 第一階段
第二階段
第三階段
第四階段
這裡應該是一個三維的圖形，有時間次元，主次要次元，緊急不緊急次元
對這個主要次要，緊急不緊急是不是眼熟，沒錯，在很多如何高效工作上都有類似的方法，把要做的事情分成重要緊急，重要不緊急，不重要緊急，不重要不緊急。
其實我不太認同将事情劃分成重要或者不重要，緊急或者不緊急，我建議大家将自己手頭要解決的問題劃分為重要或者不重要，緊急或者不緊急，因為事情隻是一種方案或者手段，區分問題本身的重要度和緊急度才是思考的源頭（包含問題的升層思考）
要填滿這張表格必須結合對業務的了解，和對産品的了解，尤其是業務了解，如果沒有業務了解，很難準确的刻畫問題。
可是什麼叫問題的重要度呢？我也思考了很久，終于得出了一些較為自洽的解釋。
三、問題的嚴重程度
問題嚴重程度的定義 當我們明确的定義問題之後，我們就要設定目标來解決這個問題，但是現狀是殘酷的，我們目标和現狀之間可能存在巨大的落差，這個落差的程度就是問題的嚴重程度，是以說：
問題的嚴重程度是希望（目标）與現實的落差！
有些書或者文章裡這樣定義問題：問題 = 目标 - 現狀，這個定義是模糊的，因為目标-現狀和這張圖一樣，往往表示的是落差，落差往往讓人想起差距，用差距來形容問題是含糊不清的，很難讓人一下子就明白問題的本質。
我們拿性能問題舉例，我們的目标是RT<1秒的請求占比大于98%，目前的現狀是RT<1秒的請求占比為80%，那麼這裡的差距就是98%-80%=18%，這18%就是問題嚴重的程度，但是這18%絕對不是問題本身，這18%是問題的嚴重程度。
衡量問題嚴重程度的挑戰
要區分問題的嚴重程度有兩個挑戰：
1.現狀：對現狀有準确的認知，比如該例中某系統RT<1秒的請求占比為80%
2.期待（目标）：問題解決後的狀态有個清晰的表述，比如該例中某系統RT<1秒的請求占比大于98%
對于數值型的現狀，我們要搞清楚這個數值是容易的，隻要将你的目标值減去現狀的值就可以得到問題的嚴重程度了。 對于難以量化的現狀，那要摸清楚問題的嚴重程度，可能需要一些案例，需要一些資料統計，比如說架構現在不合理是個問題，這個問題嚴重到什麼程度，那可以計算一下最近半年的需求在實作的過程中，花費了多少工時，如果架構合理的情況下哪些工時是可以節省掉的。或者現在的架構上疊代需求故障和bug的情況是怎麼樣的，評估一下重構之後故障和bug率會降低到多少。
隻要現狀和目标有一個沒清晰，那我們就很難判斷出問題的嚴重程度在哪裡。
FBI warning： 如果你不能确定問題的嚴重程度（現在的或者将來的），不要貿然行動去沉迷于方案的設計。
而不定義問題，不評估問題的嚴重程度，往往是很多工程師的常見思維習慣，大家可以對号入座。
而問題的緊急度和重要度的評估類似，不再贅述，大家自行腦補。
四、問題的分類
基本上看這三類問題的字面意思就可以知道這三類問題的差別了：
1.恢複原狀型：原本就應該是這樣的，但是現在不是，比如說原本輪胎就應該是充滿氣的，但是現在紮了個釘子，是以我們要讓輪胎恢複原狀，這就屬于恢複原狀型問題。
2.風險防範型：問題可能發生，也可能不會發生，但是一旦發生，帶來的危害是巨大的，是以我們不得不廢大量的精力來防止這樣潛在的問題發生。在安全和可用性方面，很多工作都是屬于風險防範型。這裡的尴尬之處是做了對數字名額可能沒什麼提升，但是不做可能會發生特别嚴重的事故，帶來極其負面的影響。
3.追求理想型：知道未來會發生的沖突是什麼，提前解決未來必然會發生的沖突。
如果将這三個問題映射到架構上，那麼應該是如下的描述：
1.解決架構上未來會遇到的問題：已經明确預知到未來的業務問題，并且可以轉換為未來的架構問題，提前做架構準備（功能性&非功能性）。我根據自己的了解又将其劃分成兩類：
•目标是非常明确且可以用數字衡量的：比如性能問題是可以準确定義一個名額來衡量問題目前的具體的量化值的，RT要到降低到多少毫秒，QPS要提高到多少，穩定性要提升到幾個9等等，基本上非功能子產品都可以用數字來衡量，比如我們系統中出現的資料搬移的功能，都是目标明确，且可以用數字來衡量的。或者比如系統的可擴充性要達到什麼程度，是否滿足95%以上的需求下不需要進行大量重構。
•目标是不明确的：比如将來要走哪個方向，要做什麼樣的技術準備，很多的類似的場景是很難直接評估出一個度量名額的。可能隻有一個願景和使命，根據這個願景和使命來分解問題，然後我們才能設定通往這個理想的問題的路徑，而探尋到這個理想的過程是相當的複雜，要考慮的因素實在太多，我隻能說這個東西我的經驗真的不多，我隻能嘗試用我所學的内容來進行自頂向下的推導，而以目前的功力實在很難保證結果的正确性。
2.解決架構上目前已經發生的問題：架構上的問題已經發生了，要對架構目前的問題進行識别，定義，以及解決（功能性&非功能性）。
3.解決目前架構合理疊代的問題：我們在架構上進行大量疊代，疊代過程中往往容易給架構挖坑埋雷，我們應該盡可能避免這樣的情況發生（功能性&非功能性）。
這三大問題正是各線任意一個粒度的架構師需要明察，并時刻提醒團隊的三大問題。如果無法定義這三大問題，那麼這裡可能就是最大的問題。
這裡還要闡述一個問題：即使是未來的架構，我們還有分類，一類是你走在最前面，一種是你跟着别人，你跟着别人要怎麼跟上去。
這裡應該有個決策分支，告訴我們遇到什麼場景的時候應該用什麼樣的思考方法，不過這隻是個人總結，每個人腦海裡應該都有一套類似的方法，而且這套方法是在不斷的突破和修正的。
五、問題定義中的常見問題
1.誤把方法/手段當“問題”
接下來，我編了三個小故事，大家從故事中感受一下手段和問題的差別，以及我們如何才能避免把手段當做問題。
案例一：鲧治水着重在堵的方法上，畢生精力都在思考如何更好的堵
•老師：請問這裡的問題定義是什麼？
•小明：這裡的問題是如何堵！
•老師：其他同學也說說這裡的問題定義是什麼？
•小紅：這裡的問題是洪水和生命财産的沖突！堵隻是解決這個問題的方法或手段。
•老師：如果問題的定義是問題是洪水和生命财産的沖突，堵隻是方法，那麼還有什麼方法可以解決這個問題？
•小王：還可以用疏通的方法來治水。
•小白：我們還可以搬走，以避免水患
•老師：恩，這也是一個思路
案例二：如果我問我們的客戶他們想要什麼，他們會告訴我他們需要一匹更快的馬 by 亨利福特
•小明：這裡的問題是如何讓馬跑的更快！
•老師：還有其他同學能說說這裡的問題定義是什麼嗎？
•小紅：這裡的問題定義是如何更快的到底目的地，馬隻是一種手段
•老師：是的，如果馬隻是一種手段，而不是問題的定義，請問還有什麼什麼手段可以解決我們提到的問題
•小王：根據目的地的距離的不同，我們可以選擇坐飛機，做火車，開汽車
•小明：老師，我不知道自己不知道，我不知道有汽車，火車，飛機，我隻知道馬，是以我想到的就是如何讓馬跑的更快
•老師：是的，我們的局限往往是受限于我們的認知，這種情況不可避免，唯一的方法就是不斷的學習，提升自己的認知。
案例三：如何做好資金防控？
•小明：這裡的問題是如何做好資金防控，怎麼防，怎麼控。
•小紅：這裡的問題定義是如何避免公司産生資金上損失，防控隻是手段
•小白：資損防控解決直接問題是避免公司産生資金和名譽的損失，這個問題背後更深層次的是社會信任的問題
•老師：小白，你的名字雖然叫小白，但是你的思考一點都不小白，顯然你在思考問題定義時使用了升層思考的方法，看到了問題背後的問題
•小明：老師，為啥我每次思考的時候，都是在思考解決問題的手段，都沒有看到問題定義呢？
•老師：那你可以嘗試自問自答，比如你可以問自己資損防控是手段嗎？自己給個回答，如果回答是yes，那麼再問自己：如果資損防控是手段，那麼資損防控是解決什麼問題的呢？通過這樣的自問自答的方式，基本上我們可以較為準确的找到問題的定義
•小白：老師，我在想資損防控解決的是社會信任的手段之一，但是解決社會信任問題的手段不止一種啊
•老師：小白，你在思考問題時使用了升層思考，在思考解決方案時使用了升維思考，給你32個贊
•小白：謝謝老師，此時此刻我有點開心啊
•老師：保持心态的平穩，可以看到更多的東西，謙卑的态度沒了，那自己的局限也就到了。
•小白：謝謝老師提醒，我記住了。
三個故事看完了，總結一下，這三個故事的核心在于：
1.準确區分手段和我們要解決的問題本身，這種情況非常非常非常常見，我review的很多技術方案之是以有問題基本都是問題定義沒有搞清楚，是以解決方案的也就不符合需要了。
2.思考問題背後的問題時使用升層思考，在思考問題包含的子問題時使用升維思考
3.當升層思考之後，之前的問題可能會變成手段/方法。比如說用堵解決生命财産問題，堵是方法。升層思考之後，生命财産問題背後的問題是民生問題，此時保護生命财産就是解決民生問題的一個手段/方法。
當然當我們無法準确的分辨問題的時候，我們還可以不斷縮短描述問題句子，比如提煉主謂賓，如果還不能清晰的描述那麼在這幾個詞裡再找出最最最關鍵的詞，尤其是主語或者賓語中的詞彙非常重要，它有可能就是重點，隻是我們無情的忽略它了。
把手段或者方案當問題，或者把技術方案中的挑戰當做問題是很多同學遇到的問題，請大家
2.誤把挑戰當"問題"
當我們明确定義出問題之後，我們開始解決方案的升維思考，可以從各個角度來給出解決方案，這些解決方案就是我們前面說的手段/方法。
舉例：如果快速到達目的地是目标，而馬，汽車，飛機，火車隻是手段/方法，那麼如何讓馬跑的更快，如何讓汽車跑的更快，如何讓飛機飛的更快，如何讓火車開的更快就成了挑戰。
此時如果你說“讓馬跑的更快也是個問題啊”，确實，廣義上也可以這麼了解，但我不建議這樣做，原因是這樣我容易将問題和手段/方法攪混。
是以這裡我嘗試給他們一個定義，以明确他們出現的場景：
•問題：事物之間在某個時期存在的沖突，在本文的語境中尤其是指企業的客戶和某種事物，趨勢之間的沖突。
•挑戰：解決沖突的方案中最困難的幾個地方
接下來我們回到上述的幾個案例中，來看看挑戰和
•回到用堵治水的案例上：
•問題定義：洪水和人民生命财産安全的沖突
•手段/方法：堵水
•挑戰：擷取息壤，以築三仞高堤，這是手段/方法的挑戰
•回到福特的案例上：
•問題定義：如何讓人更快的到達目的地
•手段/方法：造汽車來讓人們更快的到達目的地
•挑戰：設計出更高的扭矩，更高的功率的引擎，更平順智能的變速箱等等
這樣我們在溝通的時候，就能明确的知道對方到底是在産生客戶的問題定義，還是在闡述方案中的難點和挑戰。
3.思考問題時缺少時間次元
單個問題在時間軸上的不同時期的嚴重程度是不一樣的，比如說閉關鎖國公元後1500年-1700年是看不出太大的問題的，但是，300年後的1800年，閉關鎖國的弊端就開始浮現了，當然我們都是事後諸葛亮。
是以任何一個問題的嚴重程度都有一個時間軸，也許過了某個時間點之後，問題便不再是個問題。比如外賣興起之後，如何更好的制作一包友善面以滿足使用者的口味需求就不是一個問題了。
時間次元是一個及其重要的次元，任何事情理論上都必須考慮在時間次元上的影響，是以即使在定義問題上，時間次元是一個不能不考察的次元。是以才需要一個roadmap的路線圖，标注不同階段要解決什麼樣的問題。
六、升層思考及升維思考
我們不能用問題發生時的同一層次思維來解決問題。 原文:The significant problems we face cannot be solved at the same level of thinking we were at when we created them. - by 愛因斯坦
愛因斯坦闡述了思維存在層次這一現象，這裡我發表另外一個觀點：
我們不能隻局限于問題本身，還需要看到問題背後的問題，然後才能更容易的找到更多的解決方案
我把這種方法叫做問題的升層思考，接下來我會簡稱之升層思考，我在網上搜尋了一下，之前沒有人提起過這個詞，是以這個詞目前版權在我這裡哈，如果你想說服誰需要用這種思考方式，不妨把我這篇文章發給他。
當問題升層思考之後，前面的問題會變成手段/方法，比如說洪水和人民生命财産的沖突背後的問題是社會的穩定性問題（1和2是升層思考），而升維思考洪水和人民生命财産的沖突的時候就會發現用疏通治水或者搬走都是方案（3是升維思考）。
這就是升層思考問題，升維思考手段/方法。不過這張圖中每個問題到底嚴重到什麼程度，還沒有給出量化，不過我們在工作中，我們是要量化這個嚴重程度，而且要放在時間軸上來進行量化，因為有些問題目前可能并不嚴重，但是數月後可能會變成大問題。
值得注意的是這裡思考的升層是依賴認知更新的，就像一個小朋友，也許也能升層思考，但是其認知的程度決定了他思考能到的層度，是以曆史，社會科學，哲學也是我們的必修課，有助于我們認知到更高的層次的存在。當問題的層次不斷提升的時候，往往最終會歸結為社會問題和人性問題。
重要的話說三遍： 缺乏升層思考的升維思考是不完整的自頂向下 缺乏升層思考的升維思考是不完整的自頂向下 缺乏升層思考的升維思考是不完整的自頂向下
網上實際的案例來進行升層思考和升維思考 接下來我拿一些網上橫向思考的案例，來使用升層思考和升維思考的方式獲得相應的解決方案
•例一：遊客有時會從帕台農神廟的古老立柱上砍下一些碎片，雅典當局對此非常關心，雖然這種行為是違法的，但是這些遊客仍舊把它作為紀念品帶走。當局如何才能阻止這一行動呢？
•問題定義：如何給客戶提供紀念品
•升層思考：客戶需要紀念品的背後是想解決什麼問題？是不是解決客戶的旅遊紀念的需求。
•對背後的問題升維思考：要滿足客戶的旅遊紀念的需求有沒有其他方法
o明信片：明信片也可以做為一種紀念的方式，有了明星片做紀念，遊客敲石柱的比例可能會下降
o現場照片：可以安排現場拍照的攝像師，選擇特别的角度為這些想要留念的客戶拍攝特别的照片，遊客敲石柱的比例可能會下降
o帕台農神廟模型：可以制作各種帕台農神廟的模型，讓客戶購買，以滿足客戶紀念的需求，遊客敲石柱的比例可能會下降
•對原問題升維思考：
o在地上灑上大理石碎片：讓客戶以為這是帕台農神廟的大理石，客戶會撿起地上的大理石碎片帶回去留念【這是網上的标準答案】
o進入神廟時寄存各種金屬物件：讓使用者無法用金屬去砍古老立柱，缺點是成本高，效率低，需要排隊檢測金屬物件
o把柱子圍起來，讓使用者隻能在一米開外的距離觀看：使用者碰不到柱子，自然無法去砍柱子，成本比較低，也比較容易實作
o寫智語，在入口處，以及門票上明确指出破壞文物是違法行為，會受到法律的制裁
o等等
網上的标準答案是在柱子旁邊灑上大理石碎片（其他的都是我使用升層思考和升維思考瞎想出來的，你也可以想出很多）。讓遊客以為這是神廟已有的碎片。不過這種方案經不起邏輯思維的推敲，比如開放了這麼多年，地上的碎石為什麼還沒有被撿光？于是遊客就知道這是人為灑在上面的，那麼有些遊客會繼續破壞石柱。
我想說的是，這裡的升層思考，和不同層次的升維思考會給我們帶來很多種方案，如果集合全團隊的力量，我們甚至還可以想出更多更多的idea。
•例二：在美國的一個城市裡，地鐵裡的燈泡經常被偷。竊賊常常擰下燈泡，這會導緻安全問題。接手此事的工程師不能改變燈泡的位置，也沒多少預算供他使用，工程師應該怎麼辦？
•問題定義：如何不讓竊賊擰下燈泡
•升層思考：不讓竊賊擰下燈泡是為了解決什麼問題？是為了解決預算不足的問題
•對背後的問題升維思考：解決預算不足有沒有其他方案？增加預算？募捐？防止竊賊擰下燈泡。
•對原問題升維思考：不讓竊賊擰下燈泡可以從哪些次元進行考慮
o焊住：缺點是燈泡壞了之後很難更換
o反向螺紋（竊賊在擰下燈泡的時候其實是在擰緊）：缺點時竊賊隻要使用逆向思維就能破解【反向螺紋是網上的标準答案】
o特别的螺紋（特别螺紋讓竊賊拿到燈泡之後也無法在其他地方使用）：缺點是需要定制，成本高
o攝像頭：缺點是增加了裝置，需要更大量的投入
o把燈安裝在更高的位置：竊賊得用梯子才能去盜竊燈泡，要看線路是否支援
o在燈泡上印上地鐵專用标志：别人不敢買這種燈泡，竊賊無法銷贓，缺點是多一道工序，燈泡的成本變高
在這個案例中，反向螺紋是标準答案，缺點是竊賊隻要使用逆向思維就能破解。其他都是我自己通過升層思考和升維思考想出來的，其實你也可以想出很多，這裡跟邏輯無關。我想說的是通過升層思考和升維思考，我們就會發現很多種創新答案。而不會沿着某個答案一直往下走。
這兩個例子是關于橫向思維（和升維思考類似）的例子，但是通過我們會發現如果加上升層思考，在每個層次上再進行升維思考，我們會得到很多創新的idea。如果讓整個團隊使用這一的思考方式，我們就可以得到更多更多idea。
七、是新問題還是新技術解決老問題？
我們做架構的時候，一般都會根據目前流行的技術趨勢來解決問題，這些流行的技術趨勢其實手段的更新，并不是問題的更新。
尤其是在一些社會性問題以及人性問題上，幾千年來問題都沒有變化過，隻是新的技術手段可以更好的解決這些問題而已。
比如人類有溝通需求，數百年前是通過書信，後來是電報，後來是電話（音頻），後來是視訊等等。都是技術的革新來更好的解決已有的問題。這就要求我們随時關注新技術，并和目前自己手頭的工作産生一定的聯想，不同對象之間的聯想能力此刻變的無比重要。
當然在一些問題特别明确的領域，比如說資料庫領域，要解決的問題基本沒有變過，但是問題轉換成的名額的值卻在一直提升，比如支援的資料量越來越大，插入的速度越來越快，查詢速度越來越快，比如最近就有很多通過AI來做自動tunning和AI索引優化的，都屬于此列。
類似的例子還有很多，比如Mobile流行的時候，消息的更實時觸達是改造各種消息通道的一個契機，會産生新的産品，比如微網誌，微信，等等。地理位置可以擷取之後，也出現一堆新的應用，改造了老的産品。
是以我對自己提了一個要求，任何新技術，哪怕是很小的新技術，都要聯想一下可能對現在的工作，以及現在工作的産業鍊路上下遊有咩有什麼幫助，這種聯想可能不隻是個人要做的，而是要驅動團隊展開讨論的。目前眼前被提到的新技術有AI，區塊鍊，IOT，5G等等，這些也許可以跟我們的業務産生連結。可以組織團隊進行發散型思考。
不過這個事情我自己做的也一般，想多跟大牛們學習學習。
八、小結
- 區分手段和問題
- 明确問題定義
- 對問題背後的問題進行升層思考
-
對問題的分解進行升維思考
升層思考和升維思考有時候是創新的核心，比如鲧用堵治水，他畢生都在思考如何堵，是以他是從堵這個頂點向下思考的，如果對堵進行升層思考之後再進行升維思考，你會發現除了堵水，還可以用疏通的方式，還可以搬走等等。是以創新的關鍵在于升層思考和升維思考。
我們團隊已經在很多場合使用這些思考模式進行了技術上的創新，隻是這塊和行業相關，不夠通用，是以我找的例子都是以不需要背景技術知識就能了解案例為主。如果需要技術上使用升層思考和升維思考的案例，可以釘釘聯系我。
而接下來的的一些業務思考中，我将會闡述如何将升層思考運用于業務分析中。
此處說明一下，因為升層思考的方式是我個人的一些總結，是以其必有不完善的地方，如果大家看出其有不合适的地方，請務必提出質疑，助我提升，謝謝。即使沒有看出有問題的地方，也請大家辯證的來看升層思考。