幾乎每隔一段時(shí)間,企業(yè)就會達(dá)到一個瓶頸期 — 在這個時(shí)間段,我們?nèi)绾稳ネ黄婆R界點(diǎn)?相信在這個節(jié)點(diǎn)上,更有意義的事情是學(xué)會嘗試在任何事情上做一些轉(zhuǎn)變,而不是去抵制它。
比如,讓我們想象一下:
你公司研發(fā)的APP在業(yè)界有了開創(chuàng)性性的業(yè)績。營銷人員和銷售人員非常圓滿地完成了他們的工作,市場上的下載量也以極快的速度增長。不幸的是,公司內(nèi)的開發(fā)人員和運(yùn)營部門沒有跟上規(guī)模,他們無法及時(shí)升級應(yīng)用并發(fā)布新功能。你開始擔(dān)心用戶會漸漸失去興趣,因?yàn)锳PP錯誤太多,而且性能還有很多不足之處。
此時(shí),你作為老板,能做一些什么事情來糾正這種情況并拯救公司?
嗯,實(shí)際上你可以做很多事情。..。..
比如說,雇用更多的開發(fā)人員和測試人員來填補(bǔ)人員不足……
但是,如果你閱讀過一些DevOps的文章,就可以明晰地確定哪些是真正急需改善的事情:
1、提高應(yīng)用質(zhì)量。
2、增強(qiáng)用戶體驗(yàn)和客戶滿意度。
3、提高運(yùn)營效率。
4、提高員工的工作效率和關(guān)鍵績效指標(biāo)。
5、降低與IT相關(guān)的成本。
這時(shí)候,你真正應(yīng)該做的是盡快聘請一個對DevOps有所了解的人。
但是又應(yīng)該聘請誰呢?是需要聯(lián)系專業(yè)的DevOps咨詢公司,還是給員工們聘請一個資深的DevOps工程師?
當(dāng)然,如果你一生都在IT行業(yè)當(dāng)中工作,可能這些對于你就不是些什么大問題。然而,對于大多數(shù)的企業(yè)主來說,這確實(shí)是一個艱深的問題。
在本文中,我將深入探討業(yè)務(wù)領(lǐng)域,并盡力闡明DevOps工程師與DevOps顧問之間的區(qū)別。
01:顧問和工程師的區(qū)別在哪里
我們先要弄清楚,哪些人是DevOps顧問? 哪些人是DevOps工程師?
首先,我們來定義一下DevOps顧問和DevOps工程師:
DevOps顧問:
DevOps顧問是經(jīng)過認(rèn)證的DevOps專業(yè)人員,通常受雇于解決特定問題或教育員工怎么去使用DevOps工具,并如何根據(jù)DevOps的原則工作。
DevOps工程師:
DevOps工程師是指一名內(nèi)部技術(shù)人員,經(jīng)過培訓(xùn),能夠以經(jīng)濟(jì)高效的方式將DevOps實(shí)踐應(yīng)用到IT組織中,并且通常根據(jù)DevOps架構(gòu)師(或由DevOps咨詢公司提供)創(chuàng)建的設(shè)計(jì)行事。
基本上,前者提供指導(dǎo)并分享有關(guān)解決手頭問題的方法的見解,而后者主要側(cè)重于根據(jù)既定程序進(jìn)行特定設(shè)計(jì)工作。
02:如果你是老板,雇傭誰?
DevOps不再僅適用于大型獨(dú)角獸公司。如果想要更有效地管理IT組織,技術(shù)創(chuàng)業(yè)公司,甚至中小型企業(yè)都開始去選擇DevOps轉(zhuǎn)型。
需要解決特定問題的企業(yè)(例如,實(shí)現(xiàn)更快和更高質(zhì)量的應(yīng)用更新)最好雇用DevOps顧問。
因?yàn)镈evOps顧問的職責(zé)是將評估你們公司的具體情況并提供具體提示和后續(xù)步驟。然后,業(yè)務(wù)所有者來決定要不要選擇與DevOps顧問協(xié)作,去實(shí)施所需更改。
如果是需要徹底改革技術(shù)相關(guān)流程和實(shí)踐的必要性的公司,可能就更需要鼓勵在其IT組織中建立一個獨(dú)立的DevOps角色- 一個DevOps工程師。(有些人甚至可能會考慮聘請DevOps架構(gòu)師為他們的組織創(chuàng)建設(shè)計(jì),以及DevOps的行業(yè)傳道者去監(jiān)督文化轉(zhuǎn)型)
不幸的是,好的DevOps工程師很難找到。 DevOps工程師現(xiàn)在在美國已是排名第二的熱門職位,而且目前業(yè)界關(guān)于該職業(yè)的爭議也導(dǎo)致DevOps工程師對于什么應(yīng)該做,什么不應(yīng)該做這件事沒有一個明確的界限點(diǎn)。
有些DevOps工程師可以一個人擔(dān)負(fù)起監(jiān)督IT部門整個DevOps流程的轉(zhuǎn)換,甚至包括文化方面的轉(zhuǎn)換,但有些DevOps工程師只是可以管理實(shí)行DevOps生命周期的一些特定階段的工具,比如Jenkins,Maven和Ant等特定工具。
需要注意的是,大多數(shù)所能找到的DevOps工程師以前的崗位都是開發(fā)人員崗或系統(tǒng)管理員崗,并且比較擅長的能力范圍也僅限于此。
因此,公司必須非常具體地了解你所聘用的DevOps工程師能夠做什么。否則很容易最后發(fā)現(xiàn)自己冒險(xiǎn)地雇用了一些可能無法通過預(yù)期的人。
換句話說,即使企業(yè)主可能會堅(jiān)持雇用DevOps工程師來協(xié)助公司的Dev和Ops團(tuán)隊(duì),他們也可能最終去支付第三方的DevOps咨詢服務(wù),為他們的DevOps工程師創(chuàng)建具體路線圖。
03:對DevOps顧問存在的一些爭議
雖然聘請DevOps咨詢公司對大多數(shù)企業(yè)(特別是中小型企業(yè))來說可能更具可行性和成本效益,但首席執(zhí)行官,首席技術(shù)官和首席信息官通常會對DevOps顧問產(chǎn)生偏見。
他們害怕:
1、DevOps顧問只會耽誤時(shí)間,并且不會盡力解決公司的問題。
2、他們會向顧問支付太多費(fèi)用,而內(nèi)部員工可以少花錢做同樣的工作。
3、DevOps顧問可以訪問機(jī)密和業(yè)務(wù)敏感數(shù)據(jù),然后利用這些機(jī)密性數(shù)據(jù)。
4、顧問永遠(yuǎn)不會完成他們的工作,并且有可能會在公司的DevOps轉(zhuǎn)型過程中放棄。
說實(shí)話,有時(shí)所有這些事情都會發(fā)生。但是,它不應(yīng)該成為阻止老板雇用DevOps顧問的理由。
請考慮以下幾個因素:
1、并非每個人都有成為顧問的技能(不要將顧問與常規(guī)承包商混為一談。)
2、顧問的專業(yè)知識使他們能夠在不去考慮任何第三方的影響下提供專家建議,前提是他們需要時(shí)間熟悉客戶的流程。只有這樣他們的價(jià)值才會有體現(xiàn)的地方。
3、DevOps顧問和DevOps工程師不太可能做同樣的工作。聘請顧問是請他對公司IT轉(zhuǎn)型進(jìn)行分析,提供見解和教學(xué)任務(wù),工程師是去實(shí)施具體策略來驗(yàn)證的人。
最后,每個人都會犯錯誤。如果出現(xiàn)任何問題,在此之前任何企業(yè)需要考慮做好與合法人員聯(lián)系解決問題的準(zhǔn)備。
04:結(jié)論
經(jīng)驗(yàn)豐富的DevOps顧問和經(jīng)驗(yàn)豐富的DevOps工程師,這兩者在市場上都是一種稀缺商品,完全取決于企業(yè)主決定雇用誰來使他們的企業(yè)受益。
當(dāng)然,他們可能沒有任何技術(shù)背景。
所以這兩者的差別是這樣的:
顧問擁有鳥瞰企業(yè)IT全景的能力。他們判斷和檢查什么是對的,什么是錯的,去為員工們提供指導(dǎo)和教導(dǎo)工作。通常,他們幫助公司調(diào)整他們的Dev和Ops團(tuán)隊(duì),并簡化這些團(tuán)隊(duì)的流程和實(shí)踐。
而DevOps工程師的制作是以經(jīng)濟(jì)高效的方式正確地完成工作,他們的能力凸顯在根據(jù)公司的戰(zhàn)略去正確地支持一個健康的DevOps環(huán)境。
-
工程師
+關(guān)注
關(guān)注
59文章
1589瀏覽量
69248 -
devops
+關(guān)注
關(guān)注
0文章
120瀏覽量
12411
發(fā)布評論請先 登錄

硬件工程師看了只會找個角落默默哭泣#硬件工程師 #MDD #MDD辰達(dá)半導(dǎo)體 #產(chǎn)品經(jīng)理 #軟件工程師

(仰天長嘯)為什么受傷的總是硬件工程師...#MDD#MDD辰達(dá)半導(dǎo)體 #電子工程師




硬件工程師的終極幻想:焊板子焊上人生巔峰!#半導(dǎo)體器件 #硬件工程師 #MDD辰達(dá)半導(dǎo)體

不同時(shí)期的硬件工程師,最怕發(fā)生的事 #電子工程師 #硬件工程師 #內(nèi)容過于真實(shí) #YXC晶振 #揚(yáng)興科技
汽車軟件DevOps解決方案

devops使用最廣泛的集成工具盤點(diǎn)
Devops工具鏈集成的意義及基本原理
常用的devops工具集成方法

硬件工程師VS軟件工程師|硬件工程師看到這都淚目了!#硬件設(shè)計(jì) #硬件工程師 #電子工程師 #軟件工程師
FPGA算法工程師、邏輯工程師、原型驗(yàn)證工程師有什么區(qū)別?
在KubeSphere 容器中快速部署使用 GitLab 并構(gòu)建 DevOps 項(xiàng)目


評論