<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                企業??AI智能體構建引擎,智能編排和調試,一鍵部署,支持知識庫和私有化部署方案 廣告
                > 原文出處:http://www.infoq.com/cn/articles/effective-ops-part-02 > 作者:蕭田國 ## 前言 本專欄的第一篇文章獲得諸多同行贊許,也被多位技術大佬轉發、點贊,確屬始料未及。興奮之余,誠惶誠恐,思來想去,唯有繼續碼字,方能聊表謝意。也預祝大家在羊年里幸福快樂,心情愉悅。 春節剛過,廣大運維朋友又面臨著新的工作壓力。讓大家苦惱的是,我能力這么好,為什么不幸福?怎么能讓工作不那么累心,怎么能多些成就感?甚至,還有機會幸福嗎? 通常,幸福感很大程度來自于外部的認同(以及基于此的自我認同),例如外部門、領導或同事的贊賞。應該只有極少數的人,能在不被外部認同的情況下,還能自我陶醉(那該是何等強大的內心啊)。 導致技術人員不幸福的原因不勝枚舉,本文主要針對個人自我管理上容易出現的四大問題,分析其根源,并試圖給出些許改進建議。因篇幅有限,至于技術、流程規范等方面的問題,以后單開專題深入分析。 PS: 文末有彩蛋哦(但…不建議直接翻頁到最后,謝謝!) 本文略長,主要目錄結構如下: [TOC=3] 好吧,我們開始。 ## 1\. 過于追求技術進步及改進建議 技術人員有時會過于追求個人技術進步,有意無意的混淆個人成長和公司要求之間的差別。這樣的結果,往往會降低客戶滿意度,即需求方對我們工作的不認同。這種不認同,又會以各種形式表現出來,并反作用到我們自己身上。 例如,新來一個業務需求,經分析,嗯,有兩種方案:1)采用新技術,大概1周完成。可用上自己關注了很久的某新開源軟件,看上去一舉兩得:個人技術有機會進步了,而且是服務于公司的項目;2)采用老套路,3天完成。但沒啥技術含量,一堆shell腳本拼湊,對個人而言是重復勞動,而且實現起來很不優雅。 我們會選擇哪個方案?實際中往往采用新技術的居多。技術人員(特別是技術能力強的同學),難免對個人能力有所自負,潛意識認為,自己很棒,任何問題基本上都能解決。于是自信滿滿地和需求部門拍胸脯,然后結果就是……(你懂的,又延期了唄。) 新技術可能導致時間不可控,開源產品可能bug不斷,中途遇到問題就麻煩了:社區不完善(發帖半天沒人回),網上搜索不到管用的解決方案。反之,老套路時間可控,甚至閉著眼睛都能交活。有差不多現成的腳本,東改改西改改,出了問題也好解決,如果業務實在催得緊,多買幾灌某牛加加班,保證按期交付。 其實,需求部門根本不在乎我們用什么技術來實現(而且他們也沒必要在乎)。對他們而言,運維是個黑盒子,他們知道的輸出結果只有兩種:搞定了,沒搞定。需求部門最無奈的是,技術人員沒搞定,然后拿一堆聽不懂的技術分析反復解說,而且自己還得在旁邊賠笑臉、假裝略懂。 正確的作法是怎樣? 首先,主觀上,需要遏制自己的那股技術沖動;其次,提前預估到各種風險,覺得難度有些大,就選用老辦法。先按時交付業務需求,然后可以利用空閑時間,搞搞新技術的實現。 這樣一來,皆大歡喜。雖然沒業務壓力的情況下,新技術的完成時間會延長很多。但不管怎樣,這時,事情的性質轉變了——由公司需求變成了個人問題。 ## 2\. 分不清輕重緩急及改進建議 運維人員其實有相當多的時間,都在用于處理日常業務需求。或者說,一天到晚都在處理故障的情況,并不多見。所以,同比例的,外界對我們的認可程度,較大程度上取決于我們日常工作的交付能力。 分不清輕重緩急是個普遍存在的問題,例如:1)新員工,剛參加工作幾年,每個業務人員都說自己的需求重要緊急,可時間就那么多,又想好好表現,于是手忙腳亂;2)老員工,多個需求、問題一涌而來,這時也難免手忙腳亂。 僅僅手忙腳亂還好說,如果因此導致人為事故,業務中斷,系統不穩定,大客戶流失,重要內部客戶不滿意,影響公司決策支持,那么就更加麻煩了,而且會嚴重損害自己的自信心和信譽值。 那么,如何避免此類事情發生呢?可以從以下幾個方面改進。 ### 2.1 給事情正確地分類 當手頭要處理的工作超過5個,就需要分類了。按照時間緊迫性和重要程度的不同,可分為緊急、不緊急,重要、不重要。手頭的各種工作,可以自己搞個白板,按四個象限,分顏色貼上便利貼。 ![](https://box.kancloud.cn/2015-09-17_55fa551002193.png) 這個圖相信不少人都了解過。現在大家可以閉目幾分鐘,回憶下,想想過去的一周,自己完成的事情,都可以放入哪幾個象限,相信結果定會讓你大吃一驚。 往往不重要、緊急的事情,占用了我們大量的時間,每個業務人員,都看上去火急火燎,甚至愿意站在辦公位旁等結果。另外,不重要、不緊急的事情,有時也會占用我們大量時間。 那么,問題來了,我們允許大量時間被自己低效地消耗掉,對自己有什么好處?好處是:逃避現實(有時也用于逃避重要不緊急事情),尋求一個心理安慰——你看,我也好忙的(備注:這些文字可能會刺痛某些同學,但這類情況還比較普遍,權當共勉!)。 ### 2.2 要事第一的關鍵所在 要事第一的關鍵所在,是將更多時間和注意力,放在重要、不緊急的事情上,而不是重要、緊急的事情(這意味著我們能實現卓越、還是止步于優秀)。我們建議至少留出20%的時間,來做重要不緊急的事情。這符合2/8原則,而且,往往也能產生80%的效能。 這樣的好處是:可以減少重要緊急、不重要緊急的事情。例如,給某大型游戲導入用戶的banner廣告出現重大Bug,該廣告雖由投放系統動態生成,但需運維同學緊急更新相應CSS文件才能在線上環境生效,這屬于重要緊急范疇;正常情況下,這屬于舉手之勞的小操作,但運維人員在地鐵上,不能穩定連入服務器。多悲催?!如果之前持續投入時間,利用Jenkins等實現了Web更新,那就可放權給需求部門自己更新,運維人員甚至不用參與。 糾結之處在于,因為事情重要但不緊急,所以容易被一拖再拖。如果各種痛心疾首后,還是仍然經常忘記重要、不緊急的事情,怎么辦?收藏本文章,時不時的閱讀一下,如此甚好。 ### 2.3 做事原則、排序原則 各種原則很多,說多了大家也都容易忘掉,這里僅列舉3個簡潔實用的。 #### 2.3.1 一次只做一件事 技術工作的特性,決定了得有整段時間(一般至少15~30分鐘),才能沉下心來、分析解決問題,才有效率。一般來說,一次只做一件事。我們看下最高指導(新華網發布于2015年1月13日)。 ![](https://box.kancloud.cn/2015-09-17_55fa5512082db.png) 有些時候,甚至可以戴上耳機,關掉QQ,忽略非重要郵件。不要把自己搞得有三頭六臂似的,貌似很忙,實則瞎忙。 #### 2.3.2 故障是第一位的 故障是最重要緊急的,也應該優先處理。這個貌似很簡單的事實,有時都會被忽略。這發生在: 1. 該類故障,并未明確規定第一責任人,大家相互扯皮; 2. 故障第一責任人,沉浸在其他問題的解決中; 3. 故障第一責任人,心急火燎地在想辦法,其他人主觀感覺和自己沒關系,沒主動跟進、群策群力去反向推動和解決。 例如公司官網無法訪問,這個情況可能是DNS有問題、Nginix掛掉了,PHP出問題了,MySQL出故障了,網絡堵塞了。各種情況都可能有,除非有智能監控,故障自愈系統,或者責任人有豐富的處理經驗,否則運維部門所有工種,都應該主動去排查自己負責的部分是否有異常,并協助相關同學分析解決。 #### 2.3.3 部門內部工作靠后 如果手頭有多個重要緊急的業務需求,應及時向上級請示,將部門內部工作排序靠后,先做部門外的業務需求。 部門內部工作,一般由運維負責人提出,如遷移Zabbix數據庫、PHP性能調優、新技術測試等。這類事情,實際上,交付日期是可協商的,往往并非重要緊急。 但也正因為是自己領導的需求,所以,往往被同學們分配更多的時間和更高的優先級,以博得領導贊賞——畢竟,給外部門做得再多,考核自己的,主要還是上級。 這是潛意識指導下的、一種合乎理性的行為,我們不能簡單的否定。所以,這方面需要運維負責人的配合:需要主動、周期性的告知部門同學這個觀點,并且鼓勵這種插隊行為(當然,前提是和上級溝通了)。 ### 2.4 怎么更好地接單? 為了更好地接單,竊以為關鍵點是,對自己狠一點:接到業務需求時,需主動問詢時間節點要求。從經驗教訓來看,事前商量好,總比事后被人催要好(雖然會有些痛苦)。有些業務需求的回答往往是:越快越好(暈)。這時就得幫助他們設定一個時間節點,而且得具體,不能模糊——如下周或元旦后。一旦達成一致,就是一個契約。 如果完不成,請提前預警。客客氣氣地說幾句好話、打個電話,真誠道歉一把。最怕的情況是,設定的交付日期早過了,需求方來問進展,然后呆萌呆萌地說:我忘了,還沒開始做…… ### 2.5 勇于說不,合理拒絕 有辦法禮貌地拒絕某些需求嗎?還真有辦法。拒絕別人得有理有據、不卑不亢。例如,在工作量非常飽和的情況下,業務方(甚至自己領導)來加塞,說又有一個非常重要、緊急的需求,需要立刻、馬上開始,而且耗時還較長。這時怎么辦? 這時可以拿出自己的工時分配表來。就說,您看,這是我最近兩周的工作安排,都有這些事情,都是給這些部門做的。如果您的事情確實需要我來完成,您可以和這些事情的需求方談一談,看是否能做個調配,或者我們也可以一起去找我的上級,看是否能做個乾坤小挪移,等等。 另外,重要緊急往往是對別人而言,要關注那種每個需求都號稱重要緊急、恨不得就給他一個人服務的同學。所以,對需求方,我們也可以甄別下,區別對待。 ## 3\. 不善表達及改進建議 不善表達更多是性格使然,關于這部分的原因分析及建議方法,在上一篇[“高效運維最佳實踐(01):七字訣,不再憋屈的運維”](http://www.infoq.com/cn/articles/effective-ops-part-01)中已有重點表述,大家可以參閱一下。本文再次提及,只是因為這個問題,情況普遍、殺傷力大,而且容易改善,效果顯著。 喜歡鉆研技術,并能尋找到樂趣和認同感,這是運維人員的普遍情況。有些同學和別人討論技術問題,也能頭頭是道,在QQ/微信上也話多、幽默。只是一遇到當面交流,就分分鐘變成了“沉默的羔羊”。 如果需求方也是個不善表達的同學,相互多少有些“宿怨”,在日常溝通中再夾雜著情緒,那可能就更加不好。有例為證。 ![](https://box.kancloud.cn/2015-09-17_55fa55147b8ba.png) 這種情況并非少見,是求虐、求投訴么?多說幾個字,用些客氣的字句、來些語氣助詞,真的那么難?必須得惜字如金么?又不是從身上割肉,不用舍不得…… 改善客戶界面,首先從意識層面反省,是否存在客戶界面不友好的問題。解決方法包括,盡量當面溝通,真誠道歉。 ## 4\. 愛抱怨及改進建議 我們是公司的一份子,小公司問題很多,大公司更有各種通病。在一家公司呆個一年半載后,往往發現不如當初期望的那么美好,心情不暢,再加上還得面對生活的各種壓力,難免各種壞情緒紛至沓來。 其中,抱怨是我們最常見的情緒之一,甚至是一種背景式的存在。觀察下我們腦海里不時冒出的自言自語,十有八九是抱怨。牢騷太多防斷腸,抱怨可能會集結成怨恨、甚至怨氣,嚴重損害自己身體。 ### 4.1 抱怨及其本質 抱怨隱含的意思是:我是對的,并將自己放在一個幻想中的道德優越感上。抱怨是一種低調的攻擊,常被用于自我保護,捍衛自我。抱怨的,都是過去的事情,會白白的消耗自己的能量。(話語可能有些刺耳,請大家盡量看完下面的文字。) 建議輕度抱怨,勿沉迷,別走心。如果把抱怨當做朋友間的一個話題,也無傷大雅,當然,希望在這些時候,你知道自己是在抱怨(觀察到抱怨的過程,很有意義,但也很難,不信你試試)。 事情不會因為我們抱怨,就變少。反而因我們抱怨,可能變得更加繁雜。 抱怨越多的人,往往是被抱怨越多的。其結果往往是,消極被動。所以好消息是,積極主動,專治抱怨。 另外,我正在策劃一個情緒管理的專題“我的戰爭”,里面有對抱怨、焦慮、恐懼等常見情緒的更多剖析,敬請期待。 ### 4.2 積極主動的真正含義 美國管理學大師史蒂芬·柯維在資深暢銷書《高效能人士的七個習慣》中,給積極主動下的定義很有意思:當我們的行為,將影響圈擴大(借此蠶食關注圈——蕭田國注),則被稱為積極主動,否則就是消極被動。 所謂影響圈,就是那些我們能掌控(直接控制)的事情;而只能間接控制、或無法掌控的事情,都屬于關注圈。 ![](https://box.kancloud.cn/2015-09-17_55fa551578481.png) 那么,我們能掌控的事情,都有哪些?思來想去,其實也就是自己的行為。如果我們管理著一個團隊,可以指揮同學們做這個、做那個,這屬于間接控制的事情。天氣,則屬于無法控制。 我們往往將注意力放在關注圈,這是導致抱怨、并且被抱怨的重要原因。 舉個例子,業務推廣因為網站不堪重負而失敗,老板開罵。這時: > 網站運營說,我早就告訴運維負責網站的哥們了,他就是不給我好好搞; > > 網站運維說,我早就告訴系統組的同事了,他就是不及時給機器; > > 系統運維說,我早就告訴采購部門了,他們一直沒給我機器; > > 采購部門說,我早就告訴供應商了,他們說缺1TB的硬盤,沒法發貨。 大家都對,但也都不對。例如,對網站運維而言,沒法把控系統運維的服務器交付日期,但自己能做的事情,真的到此為止了么?這個情況,你是否及時向自己的上級和業務部門匯報?是否真的沒辦法,從自己負責的業務中,臨時調撥下? 對系統運維而言,是否真的不能從別的業務借用幾臺服務器先扛著?對采購部門而言,是否真的不能從服務器供應商借幾臺服務器先用著? > 【問】我周遭的環境這么糟糕,我都苦不堪言了,你還讓我積極主動,你不是在往我傷口上撒鹽嗎? > > 【答】真的抱歉啊,朋友們。大家都是苦水里泡大的,個中滋味,我感同身受。只是,除了改變自己,我們真的不能再做什么了啊。權當良藥苦口了唄?一起共勉之。 ### 4.3 通力合作 如果出現重大故障,不要先假設自己負責的部分(如數據庫)是沒問題的,并帶著主觀傾向去分析問題,這樣在言語表達上可能讓人反感,而且也往往不正確。 ![](https://box.kancloud.cn/2015-09-17_55fa5516e476e.png) 另外,也不要覺得自己負責的這部分沒問題,于是對發生的重大故障,就再也不管不問、隔岸觀火。應該主動和大家一起分析討論,群策群力,解決問題。如果下次你負責的這部分出現了嚴重故障,其他人都漠然坐上觀,你是否也會寒心? 還是那句話,大家是一條線上的蚱蜢。重大故障出現了、長時間未解決,公司和外部門會說,你運維部不行、不專業。這時候,即使能獨善其身,又有什么用? ## 彩蛋 實在搞不懂輕重緩急,怎么辦?這個好辦,問上級唄,千萬別自己憋著。領導是干什么的?不就是幫屬下分憂解難的么,呵呵。甚至,偷偷地說,如果有個需求,實在完成不了了,也不要老是自己去和外部門解釋,可以請領導出面。自己領導和需求方領導聊一聊,可能大事變小事哦。 下一篇文章,我們談技術,主題暫定“高效運維最佳實踐(03):Redis集群技術及Codis實戰”,敬請期待。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看