前言
新的一年，在暫時沒有工作以及家庭的雙重羈絆的這個週末給自己放了一天假，這樣的時間尤屬難得。
我在《致所有.Net者和有夢想的朋友們 - 共勉》這篇文章中提到過，在如今的工作生活不分家的快速節奏中，為了生活和家庭，我們必須負重前行，即使每天的時間大部分都給了工作以及家庭，但是我們還是要定期給自己清理負面情緒以及釋放壓力，因為只有自己能持續成長，才能更好的抵禦年齡所帶來的危機。
所以，對於職場人來說，成長永遠應該放在第一位，關注自己的心態以及需求，這就需要給自己時間和空間思考，給自己喘息思考的時間，才能更好的看清楚方向，才能更好的厲行自己的夢想。
說話即生產力
對於大部分技術人員來說，可能我們都不會注重自己的說話，因為我們很多人都沒有意識到說話所產生的生產力。
為什麼說話就是生產力？
不知大家有沒發現，跟身邊一些思想層次很高的人談話會非常舒暢，因為這些人能快速的洞悉到問題的本質，一語中的，把問題迴歸到本質上，而不是任由別人天馬行空說到哪就是哪。
舉個例子，如果你是CEO，你希望自己重要的話語能被即刻理解和付諸行動嗎？是的，所以你希望的是說話即是生產力。
再換個場景，如果一個管理者說話沒有突出重點，而是內容或思路比較零散，你會打心底認可這個管理者嗎？下屬的執行力會強嗎？
所以好的說話，就是生產力，能夠產生很多積極作用。
說話其實就是一場看不見的硝煙。大多數人在講話的過程中，內容或思路比較零散，講到了這點又忘記了那點，說到了後面前面的話又重複說了一遍，而且還夾雜著大量的口頭禪，勢必不會帶來可觀的影響力。
一個顯而易見的例子是，在會議上，我們較多的人會把話題越拉越遠，就像脫韁野馬，以致完全脫離主題，久而久之，給人的印象就是，你說的話中，有意義的並不多，可參考度低。這無形中是在降低自己的影響力。
展現過人的說話水平，不僅是個人魅力的展現，更是影響他人與事業發展的重要技能之一。
如何提高自己的說話
我們可能會發現，越是高職位的人，可能說話越是精簡，字裡行間都是重點。同時他們在公司也更加具有影響力，因此他們的職業或事業發展也更加順風順水。
因為他們注重說話所帶來的生產力，即注重當前說話的中心以及探討問題的重點是什麼，針對明確的重點，發言流利順暢，使內容清晰有次序。
一種顯而易見的提高方式是，首先在心裡要暗示把自己放在重要的位置上，希望自己的說話能產生生產力，那麼自然而然你就會注重自己的說話，就會在說話前進行一定的邏輯梳理，使自己的表述清晰有序。
所以一切的東西，都是在於你把自己的一個定位在哪。你在意自己說話是否可以產生生產力，那麼你就要把時刻把自己放在高的立場上，注重自己說話。
像CEO一樣思考
公司最近有這樣的培訓，遺憾的是個人由於生病錯過了，但我能想象得到，核心思想是：把自己的思想層次提高，再提高！
你想擁有管理者一樣的工作生活方式，那麼你就要像管理者一樣的思考，思考什麼？換位思考，如果換成你來做，你是怎麼規劃的，你會怎麼在執行過程中採用哪些手段來降低失敗的可能性的，換言之，你會不會做得更好？
不要以為這些很遙遠，沒有培養這樣的意識的人，是很難做到量變引起質變的。
我們很多做技術的人，關注的基本都是技術層面所帶來的自我成就感，但是如果你想讓自己前進一大步，是需要在思想層面做改變了。
從企業的角度出發
我不是在畫餅，也不需要畫餅，因為我們沒有直接的利益關係，但是對於有緣的朋友，我還是強烈推薦的是，任何事情的出發點，都站在企業的角度去思考。
我明白在很多人的心裡認為，自己永遠都是打工者。拿人錢財，替人消災，做到跟工資相符的價值出來就可以了，甚至能低於這個收入的價值都行，反正公司又不是我的。
短期來說，這是對的。然而對於我們整個職業生涯來說，這是不利的，因為這樣做只會讓我們貶值，而不會讓我們升值，還會固化了我們打工人的心態。
站在企業的角度看問題能給我們帶來什麼？
首先這樣能培養自己的更高層次的思想維度，這些思維習慣的培養和積累，會促使我們做事的方法論和眼光持續成長，繼而會給我們帶來一種工作本能，成為自己的一種優勢工作思維和技能，使得自己越來越值錢。
—個人的價值在上升，在於你的優秀習慣越來越多，而同時藉助於更高的思維格局、技能和經驗，在面對各種困難時心中不慌，從容應對，作出正確的決策以及有效的執行計劃。
其次，沒有這樣的思想積累，是很難讓自己的思想有質的改變，繼而是很難為我們後續走到高職位鋪路的。
你想做老闆，翹著二郎腿抱著祕書，聽著工作彙報，沒問題的，那麼你有什麼可以支援起你老闆的位置？
我們的目標是什麼？讓自己變得更好！只有站在老闆的角度看待企業，才是讓自己成長最快的角度。
所以我建議朋友們站在更高的層次去看待問題，即使我們不能即可站在企業的角度出發，但我們還是可以比現有的角度更高一點，就是這種高一點的思想，會給我們職業生涯慢慢帶來質變的。
關注產品
只關注技術所帶來的成就感，是技術人的通病，而可能就是過於專注在技術層面，讓很多技術人忽視了產品這個層面。
這個層面對於我們技術人來說，意義何在呢？
體現技術價值的，是將技術轉化為生產力的產品本身。產品其實是各種技術解決方案的集合體，它對映的是，對通用問題的解決模式。如果你是有意在某個行業持續發展成為領域專家的話，那這些模式的積累以及深入，絕對會讓你身價不菲。
所以關注產品本身，對於技術人員的職業素質的提高是大有裨益的，也是對在職業生涯上有意成為領域專家的重要步伐。
技術再好，做出來的產品不能很好的解決使用者的痛點，市場是不會買單的，這無疑是對我們技術的一個最大否定。
要知道，除非你是在做著自己的專利技術，且這些技術就是公司的生產力，否則技術都是為你的產品業務服務的。
而且在關注產品的同時，你會發現，自己作為使用者的話，基於對技術的追求，免不了會想讓客戶在使用層面具備極致體驗模式，那麼產品的體驗這部分就會讓你的技術價值更加得到驗證。你要給客戶極致體驗，就促使你使用websocket，使用快取，使用高可用方案來支撐。
所以如果你真是一個技術追求者，那麼你必須重視你的產品本身，因為這是對技術的一個最好驗證。
關注需求本身
關注產品，其實就是關注需求本身。
我們很多技術人員，在做需求的時候，可能僅僅看到需求表面的東西，接到需求就著手編寫程式碼，這樣其實是不利於自己的思維培養的。
做一個需求，雖然不一定要像CEO以及產品經理那樣深刻了解這個功能給客戶帶來什麼價值，但至少知道這個需求是否是某一類問題中的一個，這類問題的常用解決方案是什麼，這個需求所要傳達的資訊，如何能更好的傳遞給使用者？
磨刀不誤砍柴工，在深入發掘需求本身的同時，會引導我們針對該需求衍生出一類問題的解決方案，在基於這樣的解決方案，對於再次過來類似的需求，是可以幫助我們避免做另一套類似的方案來實現的。
說到這裡，我強烈推薦的是，不要做一個需求直譯機，我們需要發現客戶的需求，是真需求還是偽需求，繼而深入發掘客戶真正需要的是什麼，抽象出來，作為一類問題的通用解決方案。
關注客戶
嗯這個層面對於技術人來說，視乎有點風牛馬不相干了。
但是如果你注重自己的技術帶來的成就感，那為什麼不重視你的技術價值最終驗證者的反饋呢？
產品給公司帶來收益，也承載著我們的技術能力，產品的價值，也就是我們技術人關注的所謂技術成就感，是要通過客戶驗證的。換言之，客戶認可了我們的產品，我們的技術才真正產生價值。
站在更高的層次看一下這個命題，當我們關注客戶後，就會引申出：產品在前期是如何推廣進而吸引使用者的？ 如何運營留住使用者的？在使用者的這些反饋資料之上，我們是如何分析並優化產品的？
好吧，說到這裡，引申出一堆可能在實際工作中跟開發工作不相及的觀點，然而我知道，對於有心在自己職業生涯勇攀高峰的人，這些思維的培養，將會對你的職業生涯產生非常重要的影響。
君不見管理層乃至CxO，更多的關注點都是在客戶身上，關注如何提升使用者的滿意度等等，而這些的最後，才是考慮使用什麼技術服務於這些。
關注客戶以及產品這兩個層面，才會使自己的視野越來越開闊，也會為自己的職業帶來更多資源。
提高自己的眼界
不管你走向哪個崗位，例如架構師亦或技術管理乃至技術總監或者CTO/CEO，開拓的視野是職業中非常重要的一環。
當你在三樓時，你能看到可能就是眼前的垃圾堆，但是當你在三十樓時，你就能看到城市的不同風景。但是如果我們不會在爬上三十樓之前，基於每一層的風景對自己的眼界進行開闊，有可能到了三十樓，你眼中還是隻是看到這個垃圾堆。
培養CEO一樣的思考，不一定會給我們帶來即刻的自我增值，但是具備了高階的眼界之後，就會幫助你在多個場合即刻脫穎而出。
遺憾的是，很多技術人員，可能會更關注眼前的風景，更多的可能連頭都不抬。
當我們埋頭默默耕耘的時候，也要時不時抬頭看天。
就像上面說的一樣，關注客戶和產品，讓自己的眼界不侷限於技術，對比自己產品在市場上的競爭力如何，其他競品的優勢以及劣勢，產品如何盈利，對手的商業模式是怎樣的，讓自己從更巨集觀的角度看待這個產品的生命力。
眼界的開拓，讓我們具備更多的選擇以及做出更好的抉擇，合理的讓技術為我們服務，這樣才會在問題的解決方案上進行更好的抉擇。
你要知道業界內的解決方案有什麼？基於什麼情況下選擇不同的解決方案？這些都需要你有這樣的眼界。
當你準備創業或者到了高階別的職位，你就會知道，團隊的組建，產品的運營模式，市場的推廣方式，流量的流轉控制，核心競爭力的建立，這些光景所讓人提高的眼界層面，是不同於技術層面所帶來的。
未來方向
我在《技術從業者的未來》這篇文章中，分享了一些個人的職業感悟，時代發展的太快，技術更新換代的太快，除了面對著家庭以及工作外，在如此高速的科學技術發展洪流中，我們還要保持不斷的自我進步，所以我們技術人更加需要明確自己未來的方向是什麼。
基礎技術能力
曾幾何時我認為，走到了管理崗位，技術將不會顯得那麼重要。
在真正做了技術管理之後，發現技術的重要程度並沒有減弱。因為我們需要做的技術決策更多了，這些決策是否會成功，就是建立在技術能力基礎之上的。
我們需要紮實的基本功，而這個基本功並不僅僅是熟知物件導向程式設計即可，還需要計算機原理，網路，部署，演算法，設計模式等等。
而且在雲生態發展迅速的時代，越來越多的企業現在或者未來都會上雲，基於雲上的技術能力，將也是當今時代的技術人應該掌握的基礎技術。
當我們決定在技術路線繼續走下去時，我們就不能忽視這些基礎能力的積累。
抽象能力
好的設計就是基於抽象能力抽象出本質，讓抽象滿足更多通用的場景。
這裡舉個例子，我們使用過高德地圖App都知道，裡面是可以查詢車輛的具體到站資訊的。比如我每天到公司有兩條路線的公交A,B可選，某天我坐了A，但是我到站下車時想知道B車到了哪裡。
於是作為產品就會很容提出這樣的需求：在地圖中我要知道坐A車到站時，B車到了哪裡。
作為開發者，很容易想到給車做一個標記功能，這樣就很容易對比車輛的位置，於是乎就往下做了。其實我們往深點想，如果期間使用者退出了地圖再重新進來的時候，我們如何找到”有狀態的“這兩輛車？於是乎又想到可以通過個人的賬號資訊進行關聯，標記的車輛可以繫結到個人的相關資訊裡面。這裡面又帶來了問題，這樣的話就會要求客戶強制進行註冊，而我們目前的很多地圖是沒有要求使用者註冊才能使用。
當我們做到這一步的時候，就體現出我們的抽象能力是不夠的，可能就會出現我上面說的需求直譯機，而這樣是對我們的職業生涯沒有任何幫助的。
產品直接的需求是能對比功能，試想如果我們地圖上提供對車輛的一些基本資訊例如車牌號，再借助GPS的能力，這樣是否就能具備區分Ａ和Ｂ車輛的能力了呢？而且基於這樣的能力，我們還能擴充其他的能力，譬如有兩輛車靠近的時候，通過公交的基本資訊告訴好友自己在哪輛車上。
你的抽象程度越高，複用能力就越寬。
Devops
試想一下，當我們需要給公司開發一款新產品，從需求到這款產品最終上線到客戶手裡，我們軟體開發者具體做了些什麼？
我相信大家都會清晰地知道，軟體最終能到達使用者的手中，有兩個層面的事情是不可或缺的：
- 應用服務開發層面(功能性需求)
- 部署上線落地層面(非功能性需求)
實際的工作場景中，我們很大部分的人都只是專注在這兩個層面中某一塊，鑑於工作的內容性質， 運維工程師和開發工程師有著完全不同的思維邏輯。
所以在這種情況下，Dev和Ops之間是割裂的狀態。
那麼Devops能給我們帶來什麼？
我們先看一下什麼是DevOps？
傳統的軟體開發流程是這樣的
而DevOps是這樣的
DevOps 是字面上 Dev 開發 / Ops 運維兩者組合，是一種重視"軟體開發人員(Dev)"和"IT 運維技術人員(Ops)"之間溝通合作的文化、運動或慣例，實際上它是一種文化 + 願景 + 方法的統稱。
DevOps 強調的是高效組織團隊（文化）之間如何通過自動化的工具協作和溝通（方法）來完成軟體的生命週期管理，從而更快、更頻繁地交付更穩定的軟體（願景）
我們為什麼需要DevOps？
當我們面對快速發展的網際網路行業，稍縱即逝的商機，業務需要快速迭代，不斷試錯，更快地交付產品和服務是我們所有公司賴以生存的條件，也是我們所有公司的願景。
因此，在這樣的願景下，用科學的方法學來指導企業通過快速的對應，迅速地部署，實現了一流的穩定性/可靠性/安全性的系統服務，讓企業擁有持續交付的能力。
在這裡，跨職能的團隊的合作並不僅僅是為了實現使用者要求的功能，他們保障的是：快速的對應在整個價值流中不會帶來對內或者對外的混亂和困擾。
DevOps打破原來的開發和運維之間的界限，將分離的兩個流程融合到了應用的研發過程中。通過自動化"軟體交付"和"架構變更"的流程，來使得構建、測試、釋出軟體能夠更加地快捷、頻繁和可靠。這些改變的目的是為了支援和適應應用快速、安全、可持續和頻繁的版本釋出。
我們如何實踐DevOps?
文化
首先DevOps是一種文化的背景下，文化的推行，肯定要涉及到思維的轉變。
DevOps並不是簡單的在組織機構上把開發團隊和運維團隊合併起來，我們上面提到它包含著思想，所以在思想層面上，需要企業文化和思想觀念的變革。
那麼想要將DevOps真正落地，第一點就是思想改革。不僅是運維的思想要變，開發也要變。員工要變，領導更要變。
DevOps並不僅僅是組織架構變革，更是企業文化和思想觀念的變革。如果不能改變觀念，即使將員工放在一起，也不會產生火花。
方法
想要充分落地DevOps，離不開工程和平臺的支援。
在更快的交付願景下，對映出來的是在整個產品交付環節的效率提升的，所以我們將在效率工程上進行效率提升。
- 開發效率
在這裡引入了敏捷開發，敏捷開發大幅提高了開發團隊的工作效率，讓開發專注於每個迭代內需交付的最小閉環功能，讓版本的更新速度變得更快。
- 測試效率
當開發團隊的效率提升後，不可避免的需同步提升測試效率。而自動化測試流程將會在DevOps設定的上下文中起作用，而且這還將需要持續測試（CT）。
如果沒有持續測試，也就不能對持續整合進行及時驗證，自然就無法做到有效的持續交付。
自動化測試是一項艱鉅的技術活動，如果沒有有效實施，它就有能力破壞總體的DevOps策略。
雖然在持續整合中要儘可能的使用自動化測試，但是難以避免有些情況是自動化測試難以覆蓋。所以手工測試還是必不可少的，但是在測試團隊的持續改進中必須將手工測試儘可能的優化，不能讓其成為自動化測試的瓶頸。
- 部署效率
減少部署層面的重複性和出錯可能性，自動化手段是必不可少的，所以我們需要提供基礎設施平臺的支撐，其中包括我們耳熟能詳的術語：CICD，觀測皮膚，容器化（虛擬化），編排工具，服務網格等，其中CICD是DevOps的基礎核心，沒有CICD自動化的工具和流程，DevOps是沒有意義的。
在我們上面做了這些效率工程之後，我們的將會大大縮短產品上市以及換代的時間，這就是我們DevOps的願景。
在有了基礎支撐之後，很重要的一點是， 我們的工作是有互動的。
在DevOps的流程下，運維人員會在專案開發期間就介入到開發過程中，瞭解開發人員使用的系統架構和技術路線，從而制定適當的運維方案來支撐自動化和研發工作。
而開發人員也會在運維的初期參與到系統部署中，瞭解部署架構以及基礎設施平臺是如何運轉的，在資源管理、監控、網路、安全等方面提供系統部署的優化建議。
在這期間，自動化測試工程師和開發工程師一起基於場景以建立測試指令碼，並在產品經理的幫助下擴大其測試範圍，並且在基礎設施平臺整合這些程式碼和指令碼作為持續測試的基礎。
後記
在這不容易的過去一年中，如果你的2020年是平安美好的，那我們應該感謝自己以及家人和朋友，如果你的2020沒有那麼美好，那麼讓我們忘掉這段記憶，在2021年重新啟航。
其實不管在哪個行業，如果你許諾了給自己或者家人一個美好的未來，那麼我們都將需好好規劃這個未來，而這個未來，我相信，並不會輕易就達成，所以我們在這之前一定要先自醒，清晰自己的方向，不能瞭解自己真實的狀況，就不會找到有效的辦法去改變現狀。
讓我們繼續加油！