這篇文章從網上得到，翻譯得到並加以自己的理解。
--------------------------------
當然你正在運營一家初創公司或者規模不算大的公司，想要招聘一些有經驗的雲工程師幫助你，本篇文章也許會為你提供一些建議。
這裡說到的「雲工程師「，其實泛指一些可能涉及到雲，或者和雲相關的技術職位。
如果你想找某人成為你的cto，或者找乙個暫時完成你某個專案的freelance，那人首先需要具備相應技術/技能以建立你的雲架構。
所以，這裡有5項關鍵的核心法則來幫助你正確評價候選人的能力，完成好招聘。
以下就是些你需要問的問題的例句，和你應該聽到候選者給你答案的範例。
一切和你的客戶息息相關
對大多數的初創公司和他們的客戶都很關鍵的5項法則：
· 可用性
· 可伸縮性/彈性
· 表現
· 解決問題的能力
· devops自動運維
可用性
為什麼這個關係到你的客戶？
如果你的行業和電子資訊有關，最糟糕的情況就是down機。
每down機一分鐘，你的客戶、收入、名聲就down一分鐘。
因此以分鐘為計數單位的down機時間就是考驗你工程師能力表現的關鍵。
當你發現，down機時間資料趨勢上公升，那你就應該覺得你的it**商是有問題的。
你應該問的問題
· 你對down機這個情況有什麼打算？
· 你設計的東西能承擔多少sla（
服務等級協議）？多少個9？
· 你如何監控乙個應用的正常執行時間？
· 你如何建立乙個可自癒型的架構?
你應該聽到的答案
「我設計的架構具有防禦性」
你的雲工程師必須知道如何在以下層級上建立應對down機的架構：
「我的心中有5個9」
你的雲工程師必須是積極的，而且也對以前的可用性資料非常自信。
「我不介意隨時待命」
這個是個好的訊號，這表示這個人對於他工作的責任以及掌握欲。
你想要的是乙個人，設計了這個架構並且可以自己運營他們。
當然還有個隱藏目的就是看下那個工程師把自己設計出的是這個完整、自癒型的stack是否還會有後續更新，而不是設計好了就放任不管。
彈性 為什麼這個關係到你的客戶
知道slashdot效應嗎？就是當乙個受眾廣泛的**介紹了另乙個小眾的**後，小眾**流量激增的現象。slashdot效應的產生大量的訪問雖然你急迫想得到的，但是你的現有架構可能並無法做到可伸縮，這樣的話，流量激增使得它的訪問速度變慢或者一時間完全不能訪問，而且當這個激增產生前和產生後，你的架構必須做到自動伸縮，以保證儘量減少成本。
你應該問的問題
· 你會如何設計你的架構以處理流量激增？
· 你如何監管大規模的專案？
· 如何測試你的系統是否有能力處理大規模專案？
· 針對正常流量和高峰流量，如何讓你的系統保持始終保持「正確的規模」？
你應該聽到的答案
「這個彈性，那個可伸縮……」
彈性/可伸縮性是雲計算帶來的最大好處之一。它可以盡可能的按需配額。這並不是說在架構中的所有元素都必須具有可伸縮性，而是你的架構需要認識到可伸縮性的重要性並在關鍵時刻點可以發揮作用。
「橫向伸縮比垂直伸縮重要」
在如今雲計算中，增加乙個額外的計算/互動/儲存到乙個既存伺服器（垂直伸縮）是小事一樁。但是最終的表現和時間成本卻受到限制。從可伸縮性、成本、彈性角度而言，可以增加/減少小型例項的自動伸縮群組的負載均衡是較好的一種方式。你的架構師應該從一開始就使用橫向伸縮。
「網路規模服務」
aws有一些可完全伸縮的非常很好用的服務（比如，aws s3,aws dynamodb，和elastic load balancing雲網路負載均衡器）。這意味著處理一些從幾個gb到幾個pb（1024tb）擴張服務時，不用或者很少用到人力干預。乙個好的雲工程師會利用服務簡化或完全緩解一些效果，比如給某個應用儲存不穩定的元素等等。
表現 為什麼這個關係到你的客戶？
頁面的響應時間是影響使用者體驗最重要的因素之一。
架構師有很多任務具可以測試出載入時間的每個毫秒都用在了什麼地方。這些載入時間會被一些因素影響，包括使用者的物理位置，伺服器處理程序以及網路頻寬等等。乙個好的架構師會優先處理那些載入時間遇到瓶頸並在戰略上統籌整個stack。
你應該問的問題
· 你會如何監視系統表現？
· 監控什麼資料最重要？
· 有沒有遇到過應用表現中記憶、計算、儲存遇到瓶頸？你的架構是怎麼處理的？
· 你是如何利用快取改善執行能力？
你應該聽到的答案
「快取資料」
當你開始伸縮業務，database都會是你的痛點。
把資料庫問詢下到快取層，比如memcache 或redis，可以讓你的應用閃電快速閱讀，也會顯著降低你資料庫的需要。
不過你的架構師必須有過在重要儲存裡快取資料的經驗。
「邊緣的快取設施」
減少網頁載入時間最有效的途徑之一就是把像影象，css，js等東西快取在離終端使用者越近的地方越好。
我說的就是cdn。所以，你的架構師必須對cdn稍有認識。
「我用過***或者yyy工具」
證明乙個架構師是否靠譜，就是看他是否負責過真實生產環境的工作負荷，而且會有針對性地選擇登入工具和監控工具。
乙個架構師的資料報告版就像飛行員的儀器板，我們得依靠這些東西保持飛機空中正常執行。
解決問題的能力
為什麼這個關係到你的客戶?
資訊公司的核心價值可以從他新功能的發布頻率中體現。保持產品更新的速度和新功能的發布，與使用者參與和滿意度密不可分。
如果你的雲工程師阻礙了開發人員的進度，
因為他「還在配備集群」或者「還在配置資料庫」，
他降低了開發人員的速度而不是幫助他們創新改進。
乙個好的雲工程會尋找每個機會把問題簡單化把同樣的事情做好。
你應該問的問題
· 你以前用過什麼託管服務？
· 你為開發準備乙個資料庫，最短需要多久？
· 什麼時候開始不適用託管服務並在直接的集群裡開始適用自主管理？
你應該聽到的回答
「為什麼不重新改造那些輪子？」
不管公司是什麼種類，普通技術需求會演變成變成乙個增長型的複雜架構，比如後台工作人員、外部郵件或者手機推送。
你要的不是那些認為只要個普通架構的工程師。
「我不喜歡管理我自己的集群」
如果有人只為他們曾運營15個集群而自豪，那就是個不好的標誌。
管理集群需要很大經歷，有時甚至是個全職工作。
管理自己的集群像水藻裡找東西。
好的雲工程師會在管理細節中使用託管服務，因此才會在stack裡更加優化工作負荷。
「我盡量避免資料行政管理」
託管資料庫服務的出現，像aws rds aurora，大大減少了運營上覆雜程度，之前都需要資料庫管理員（database administrator）負責管理。
給工作負荷選擇正確的託管資料庫的能力現在比資料庫管理經驗來的重要。
自動運維devops
為什麼這個關係到你的客戶
做實物的公司非常注重他們的實物**鏈。同樣，乙個電子資訊公司也必須高度注重devops。
想象一下你公司的devops過程就好比實物**鏈中負責確保你的產品效能送達你的客戶。
戰術上，devops意味著確保那些**寫好了，管理好了，測試過了並靠譜地沒有重複地被部署。
要知道，你公司的devops過程中斷或漏洞可能會造成down機或客戶的服務降級。
你需要問的問題
· 你以前用的是什麼版本管理器？你偏好哪個？為什麼？
· 很多人同時使用同乙個**庫的時間是什麼？在那種環境下你又是如何做的部署？
· 持續整合和持續部署之間的區別是什麼？
· 你以前用的是什麼devops工具？你偏好哪個？為什麼？
你應該聽到的答案
「這需要衡量。」
人力不夠的情況下，新增過多的devops程式和技術會降低速率。
你的雲工程應該認識到這種得失，自己進行衡量，
找出和基於各種考慮因素的合適devops，其中因素包括有：公司規模、開發者的水平、公司成長目標。
「架構即**」
如今的雲，是乙個有像aws cloudformation模板和aws elastic beanstalk 引數這種有特別格式的text檔案的整個技術架構。
如果乙個人說可以把整個架構可以在源**層管理的話，可以證明這是個與時俱進的好雲工程師。
我公司bootdev中的自動伸縮架構，就是以架構及**的形式部署到客戶的賬號下。
也算是架構及**產品化的乙個體現。
「我真tm喜歡/討厭***工具」
這是個很好的證明，說這個話有很強的自主意見，偏好使用什麼工具。
乙個如果喜歡或討厭ci或cd工具的話，其實就走在devops的路上。
結論 人發展為乙個好的雲工程是有很多因素。
我覺得軟體開發和devops可以很好地轉化成了雲計算。
不要因為乙個人沒多少雲上的實踐經驗就立即否定。
那些人如果正視並認真理解了本篇中闡述的一些觀點，他們會自己琢磨那些的雲特性。
綜上所示，你要找的是乙個可以全盤看住你的架構並有意持續優化的人。
希望以上內容對你有幫助。
科技公司需要了解的重要問題,工程師的思維和情商
我是技術出身,對於曾經共事的同事多有觀察,發現工程師的思維非常可愛,簡單,直接.會在心裡轉小九九的地方大都在薪資福利,崗位,職級等地方打轉,很少會在人情世故,雞毛蒜皮的事上的糾結.寫累了,陽台人手一根煙就是一群兄弟最真實的寫照.最近公司出了兩個新政策,讓公司工程師大為光火,公司規定 1.週末加班餐不...
IT工程師需要注意的10個問題哈
1 好好規劃自己的路，不要跟著感覺走！根據個人的理想決策安排，絕大部分人並不指望成為什麼院士或教授，而是希望活得滋潤一些，爽一些。那麼，就需要慎重安排自己的軌跡。從哪個行業入手，逐漸對該行業深入了解，不要頻繁跳槽，特別是不要為了一點工資而轉移陣地，從長遠看，這點錢根本不算什麼，當你對乙個行業有那麼幾...
後端工程師需要掌握的知識和技能總結
先來看下整體的後端技術學習脈絡，分為下面幾個大的模組，現在你心裡應該清楚，後端開發需要掌握的大體知識框架是哪些。計算機基礎 4 件套 計算機組成原理 資料結構與演算法 計算機網路 作業系統，如果感興趣，還可以學習編譯原理知識。對linux的學習，越早開始越好，不止於熟悉，還要能在上面起舞。服務資料量...