網際網路的蓬勃發展，讓無數的程式設計師身價水漲船高，都變成了「香餑餑」，更有了不少「創業」，「當上 cto，迎娶白富美的傳說」。都說不想當元帥的士兵不是好士兵，我覺得這件事見仁見智，但提公升自己的價值，讓自己變得更優秀更有競爭力，一定是一線城市的大部分 it 人內心的追求。
誠然，並不是所有程式設計師都會變成 cto，程式設計師——>cto 的路徑像是乙個漏斗，極少數人沉澱下來，在業界掀起一陣陣颶風。這些 cto 比起普通的程式設計師，強在哪？豐富的技術知識只是基礎，更重要的是戰略眼光，管理把控能力。那麼 cto 所思所想，和普通程式設計師究竟有什麼不同?
普通的程式設計師往往只負責模組的開發，**的優化，和新技術的鑽研，哦對我說的是普通程式設計師，而不是只會 fork 的小白程式設計師；而走向管理領域的高階程式設計師也許已經開始負責團隊，揹負團隊進度和效率。而 cto，往往不僅要考慮優化團隊的開發工具、流程，肩負起把控整體技術方向的重任，要具有前瞻性，同時還要對企業績效負責。尤其是技術驅動型公司，你問這樣的公司 cto 好招麼，答案通常是「很難招」。技術選型其實是創業公司最糾結的問題，很多團隊往往一上來基於已有的程式設計師的個人習慣和愛好，選擇了乙個技術方案，然後到某一天一看，我靠，全是坑（當然，也可能與執行者的能力有關）。
圖為通常來說程式設計師的發展路線：
影響企業績效的因素在方方面面，核心因素卻往往集中在產品上。不誇張地說，應用程式的效能對於企業績效有著非常巨大的影響。網際網路產品遍地開花，sdk 層出不窮，使用者對於一種新產品的嘗試時間與網際網路產品更新的速度成反比。使用者體驗這個已經被講爛的概念依然還是提公升產品價值的關鍵按鈕，無論是 2c 還是 2b。
一旦使用者未在你所負責的產品中獲得最佳體驗，或者直接解決痛點，他們會毫不猶豫的選擇其他平台。
這個問題普通程式設計師通常解決不了，而一名優秀的 cto 就需要下點功夫了。如何成為一名優秀的 cto，這是乙個問題，而乙個問題往往是另乙個問題的解決方案。為什麼乙個團隊需要優秀的 cto？是因為需要有人來帶領技術團隊優化應用效能——解決使用者體驗的難題，提公升開發、運維，把控技術團隊的戰略方向。那麼，優化應用效能，獲得好的使用者體驗，提公升開發、運維效率，又該怎麼做呢？
為了確保應用程式能夠達到甚至超越使用者的高期望，需要不斷優化底層 it 基礎設施的效能。然而，隨著基礎設施變得越來越動態化，混合化和複雜化，一波波新的挑戰隨之而生，讓不少 cto 多了幾根白頭髮。
但是乙個問題的產生，往往意味著相應的解決方法正在路上。為了優化應用程式的效能，優秀的 cto 需要足夠主動和敏捷。
主動優化包括物理和虛擬伺服器，網路，儲存裝置，資料庫，終端使用者服務，雲，和大資料環境在內的所有基礎設施。需要將 it 團隊帶領成為不僅能夠迅速識別和解決問題，同時具有強大的反脆弱性，在問題對使用者體驗產生不利影響之前，先發制人的組織。以下五大關鍵措施或許可以幫助我們實現一點。
鑑於良好效能的重要性，對於 it 團隊來說只在基礎設施元件出現問題時產生告警是不足夠的。cto 需要讓團隊能夠提前發現潛在的效能問題，並主動解決。例如，通過免費或付費的第三方工具及一些開源工具，配置告警，在問題出現之前解決。不同的團隊，往往有最為適合自己的基礎設施監控手段，優秀的 cto 需要能夠綜合衡量團隊大小，開發、運維水平，與人力和資金成本，選擇最符合公司當下情況的監控方式。對於變動型較大或者高速發展的公司，盲目增加人力和花費時間去進行自主開發系統監控解決方案往往造成時間的浪費，得不償失。
由於開源工具與第三方解決方案層出不窮，不少 it 團隊也勇於嘗試新工具、新方法。雖然有很多新的工具，解決不同方面的問題，但當問題出現時，團隊成員仍然花費許多時間開會討論，不斷地開會浪費了許多時間。而與此同時，使用者卻經歷著槽糕的體驗。為什麼明明有許多任務具卻依然採取本辦法溝通呢？原因有兩個，乙個是很多 it 團隊內部在使用不同的協作、監控等工具，另乙個是其實團隊內部並沒有養成利用監控平台或者協作工具的習慣。這種時候 cto 就需要發揮作用，採用乙個統一且功能強大的檢視和架構來監測關鍵的 it 服務，無論是虛擬機器，物理主機，雲主機，或者其他元件，同時採取深刻理解 devops，掌握提公升協作、溝通效率，優化開發流程，節省運維成本，提前發現問題的方法。
it 團隊可能擁有大量的效能指標，但是如果不知道使用者的真實體驗，就還是無法真正了解效能表現。什麼是真實的體驗？就是使用者在實際操作中，是如何使用我們的產品的，在某個介面停留多久，對哪個環節不滿意，諸如此類。it 團隊需要分析端到端的基礎設施的響應時間，並借助虛擬交易功能，持續跟蹤交易響應時間，即使在使用者不使用應用程式的情況下。
一旦企業的全面監測到位， it 團隊針對服務水平協議(slas)跟蹤效能和體驗是至關重要的。it 團隊需要能夠跟蹤 sla 合規性，當潛在問題出現時，立即識別和解決。通過跟蹤 slas，it 企業可以評估他們在管理使用者體驗和基礎設施效能上的有效性。 這一評估對於準確計量團隊績效，設定目標和跟蹤進展也是至關重要的。
滿足使用者不斷提高的期望，並不僅僅是跟蹤 it 資料。通過關聯 it 和業務資料，團隊可以主動識別瓶頸，提高終端使用者體驗。比如，將伺服器 cpu 利用率指標和簡單的歷史資料相關聯；比如，將使用者登入或交易的數量與 it 資料一起進行展示，可以為適應未來發展的容量規劃，提供有意義的見解。下圖為某團隊將 php 請求、響應時間等資料和系統效能資料一起匯入 cloud insight 儀錶盤進行展示的例子。
插播乙個好玩的，下圖為某團隊成員別出心裁將鍵盤使用記錄匯入儀錶盤進行展示，也許鍵盤記錄只是一種出於好玩的別出心裁，但同理，也可以將運營資料、業務資料、系統效能資料一起匯入儀錶盤進行展示，這對乙個快速增長的 it 團隊來說，就很有價值了。
資料驅動網際網路高速發展的時代，技術團隊 leader 除了技術過硬，眼光獨到，還要將緊跟 devops 的步伐，放眼國內外，快速、敏捷、盡可能多的優化團隊開發手段和流程，減少開發、運維、運營之間的溝通壁壘，將資料化融入到技術推進的方方面面。而當你在這些方面有了核心競爭力，就不再只是一名普通的程式設計師了。
本文** oneapm 官方部落格
好程式設計師大資料技術盤點 你都知道嗎
好程式設計師大資料技術盤點 你都知道嗎，大資料的概念，指的是無法在一定時間內用常規軟體工具對其內容進行抓取 管理和處理的資料集合。而大資料技術，是指從各種各樣型別的資料中，快速獲得有價值資訊的能力。第一，資料採集 etl工具負責將分布的 異構資料來源中的資料如關係資料 平面資料檔案等抽取到臨時中間層...
作為PHP程式設計師這些編碼規範你都知道嗎？
不得不說php程式設計師總是一不小心就被列為程式設計師鄙視鏈的底端 還好現在有前端工程師了，哈哈哈哈 那麼從php語法結構，php命名規範與預定義的關鍵字來說，確實有些定義不算很協調，但是總在底端這件事php語言也不該背鍋。據統計最近php7的使用率達到60 以上，php7的底層規範做了一些標準處理...
程式設計師這個職業的危險期你知道嗎
這麼多的職業病，再加上不分晝夜的加班，說不准哪天就又出來個胡新宇。1.近視 整天瞅著螢幕，想不近視都難。每次開技術會議，往下看都是白茫茫一片。從事it而不戴眼鏡的人，真是讓人羨慕啊。2.頸椎病 每天坐在那裡，盯著乙個地方，時間稍長，就感覺脖子僵硬。趕快去檢查下頸椎吧。3.腰間盤突出 每天坐8個小時，...