分享

Python Taiwan讀書會_12_DevOps到底是什麼

世界上很多東西看起來認識,例如DevOps的每個字母我都認識,但在這次讀書會之前,我還真不知道DevOps工程師與他們的工作內容是什麼,我也不知道裡面隱藏著許多與我想法相似的流程與工具。我認為即使是在不同領域的人,對資訊透明、分享新知、持續學習等由價值觀帶領的行為,其實是會有著驚人的相似,仔細想想,好像與專業、領域無關,畢竟有人在的地方就有江湖,成事在人,只是資訊領域的人做起這些事來,招數很多,看起來比文科生多會一點。(很大點)
在一些大公司裡,Dev是寫軟體的,Ops是管電腦的(資訊管理),DevOps和寫程式沒有直接關係,但和軟體的品質、出貨速度非常有關,2016年(四年前),王大哥組織了DevOps  Taiwan社團,現在這些技術已經到(願意接受的)各公司生根了,社團比較安靜了。當時在不同地方、不同時區的工程師,因為想學新技術而很活躍地在裡面討論,傳統的軟體開發,以銀行舉例,一個專案可以做一年多,給的費用也蠻高的,客戶自己會一直推翻自己的想法,又看到其他競爭對手的行為而產生新的想法,規格一直在調整,沒有版本控制就是打包一包用寄的,每家公司又都是一兩個工程師,公司內部不一定有正向的學習氛圍,四年前便把這些人聚集到社團裡,一起來討論技術的問題。
2020年8月開始的Python Taiwan讀書會,前幾週課程,除了程式語言外,大部分都是講資訊領域中推薦的觀念、團隊協作的方式與工作、降低嘗試新事業門檻的工具等。公司是由許多人組成的,不願意改變的人佔一定的比例,因此,很多公司無法快速接受轉變,四年前DevOps社團裡推廣的東西,多數也是新創公司才會想要用這種方法,大公司一開始頂多先接受git做點版本控制,其他東西無法讓人數眾多、已有二三十年經驗的團隊與他們的成員快速接受,另外,老闆只看結果,客戶只管UI,多數客戶並沒有能力知道背後的軟體穩不穩定,會動就好(欸不就是說我),抓bug不徹底,有問題不找原因,重開機就好(感覺很孰悉),以上都不是一個軟體大國要外銷的水平。(情懷又出現了)
對於人是慣性的動物這件事,在遠古時代可能對人類產生了保護機制,但在快速變化的時代中,我們想要享受好的習慣給我們的益處,想要去除壞的習慣給我們的傷害,又想要新的習慣給我們更高的效率、更新的體驗,這麼多要求也真是為難了習慣也為難了自己。我自己經常在工作與生活中,嘗試培養或改變一些習慣,對自己做實驗,試試看在毋須動用求生意志的情況下,只要一點點提醒和時間安排,有沒有可能變成一個自動運轉的習慣。最近三個月我養成的習慣是在上班的途中玩5分鐘Dulingo、延續之前上課整理每週筆記繼續寫學習週記,11月還想做一個英語口條的練習,以上這些目前都沒有具體的目的,純粹就是喜歡自己的生活充實,隨時隨處有新意,並且相信涓滴意念終匯成河。
講義中DevOps較扼要的解釋是,一群人做事的新方法,有效率(快速的iteration)、有彈性(很容易refactoring)、有把握(持續monitoring),而這些都在大家一起持續學習下進行。
附上講義,DevOps應該流行過,另外,AWS和Google Cloud也都在官方網頁上嘗試說明。
DevOps 到底是什麼?
DevOps - Amazon Web Services (AWS)
What is DevOps? Research and Solutions | Google Cloud

有效率(快速的iteration)

在「溝通與工作效率」這頁講義上,我看到「不要再用e-mail,改用slack」,整個笑出來,其實我也約略也是在DevOps  Taiwan社團活躍的那段期間(我那時還不知道有這個社團,但他們的腦波可能跟我有隊到),試著把這個想法傳遞給組內成員,並且幻想公司內的溝通方式也能發生改變(畢竟當時IT有提供Office365這項工具)。雖然當時匯總報表和投影片的工作不是我的任務,但我也真覺得浪費了人力在做這些的溝通和整理,等來等去等成愁/仇,即使不是浪費我的時間,我也覺得可惜,畢竟戰力是以團隊計,但似乎也只有我很在意戰力這件事。
我非常認同溝通的重要性,但很頻繁、主題不明顯的溝通,不代表是有效的、重要的溝通。
2019年5月,我參加微軟年會時,發現除了我們已經在用的Office365,功能遠大於儲存與共同編輯,下面其實還有很多app是可以使大家的溝通更好整理在不同主題或小團隊之下,像是Teams,還可以在那裏交換討論中的檔案,或是設工作分配與進度追蹤,講者是Teams團隊亞太區主管,光是招募這件事,就要同時處理不同人、不同進度、不同進度下不同的小團隊討論,而他本人看起來還是白胖可愛,顯然沒有加班加到乾掉。從年會回來,我向同組同事推薦Teams,也排了2020年起本團隊不用LINE群組的時程,並沒有受到頑強的積極抵抗(消極的就當作沒有),直到2020年下半年,公司把Teams做為內部優先使用的開會軟體,讓Go to meeting與其他會議軟體淡出,我的團隊已在2020年年初就開始適應這項轉變,雖然不想討論、不想處理的事仍舊被擱置,但我喜歡這種把事情公開在大家都可看到的地方,而選擇不回應的回應,大家都看得到。(從這裏知道,只要資訊白癡願意用的工具,應可以在全公司推廣)
讀書會中的高手同學,提到實作中,「如何快又能兼顧品質?」這個問題,王大哥的回答是:
「這是學DevOps的目的,問題是trade-off,但這個方法就是來解決這個問題。」
(小孩子才做選擇,大人全都要)
王大哥開始講的第一句話是「只有一個人想用新方法是沒有用的。」,我聽到又是整個笑出來,只能笑中帶淚啊我!他講到業內軟體工程師覺得天天加班,但加班就無法學新的東西,不如去學新東西新方法帶回公司。以溝通的工具來說,slack或telegram可以把團隊的所有訊息和bug都公開,無法忽略問題不去解決(都來直球對決真是爽快)。而版本控制的工具方面,以前用meld做兩份版本的比對,一行一行比對(聽起來就是天荒地老),用git diff可以和各個版本比對,有增減的自動標記出來,除了少數大公司還有他們的堅持,多數中小型的公司應該都已接受git。又例如部屬電腦環境的ghost,雖然有很快的部署速度,但如果五個人要五種不同的環境,ghost無法提供,傳統公司就是上班時間都在等別人,只好加班做事,用ghost雖然很快複製,但無法幫不同人客製化,例如人資主管和工讀生的環境就絕對不一樣,用vagrant、ansible、docker可以多做到很多不同需求,這些即使無法很快學會,但還是鼓勵大家一定要開始做做看。再送一個例子是,沒有ELK之前,grep是唯一方法,為何DevOps推廣起來大家接受,因為如果薪水是兩倍但效率是五倍,算起來還是很划算,用ELK去監控,不要自己花更多人做。
DevOps概念:盡量加技術,不要加人。
(你現在用的東西可能已經開始落伍,學電腦最辛苦的就是學不完。)
以上看似可以增加速度,把這些放進開發流程,卻還可以提升品質,是因為傳統只跑一圈流程,現在善用工具可以跑好幾圈。管理問題的軟體,是在管理開發人員/測試人員/PM三者之間的關係,有時候問題討論很久,是因為已經測試到不同版本,軟體工具造成雞同鴨講,這時候就會非常需要管理問題的工具,用ELK可以更好地監控(可以監看工程師們的日誌),連現在是不是硬體不夠、或是軟體哪行寫不好都能知道,所以工程師們更應該寫標準格式的日誌(這我講到大家耳朵長繭:頻繁使用的文件一定要有標準格式),讓問題可以更容易被找到,例如客戶說昨晚3點不能用,客服人員只要去找出來那個時間點與程式,開發人員在那段找bug去解決,不用等測試人員去找問題,若一家軟體公司沒有架構好開發團隊與工具,客戶發現問題時找客服,一定沒有辦法馬上服務(慢了就輸了),更好的服務,並沒有有增加的人力和成本,往往是越沒效率的運作方式,才會需要越多人力,可以多去參加開源軟體的年會,好用的軟體幾乎都有免費的版本,很多都是人少時不用錢,等變大公司才要付錢。。

有彈性(很容易refactoring)

軟體設計已經決定品質,若把1000個小模組寫成一團義大利麵,找不到哪裡要改,因此如何分模組若是能規劃清楚,後續修改才能有彈性。資訊小白(我)之前誤會軟體公司就是一群工程師瘋狂coding,但這幾個月下來發現不是這樣,也才知道沒有版本控制的軟體不要買,品質不可能會好。開始學Python沒多久,就聽到許多人強調「物件導向」,物件導向不是先寫class,真不是寫了個class就自以為是個物件導向了,比較漂亮的程式寫完了,還未必有class(我好想知道長得漂亮是長什麼樣子啊),要先寫的是interface(python叫抽象class),先寫函式,寫空的函式,寫interface先準備好,下面都可以用,例如:「形狀」是一個 interface,三角形、圓形、方形各自是class,這些class要能繼承「形狀」這個interface。
彈性不是一種幻想,用人話講,就是必須透過高密度的計畫,去架構、善用工具去執行好的工作習慣。要做到彈性,在架構上有許多要點需要滿足,舉例來說,「程式要模組化」,就是要避免日後深陷在一團義大利麵裡,找都找不到明明記得有寫過的一段程式碼,「服務微型化」,如果一個大軟體可以拆成5個服務,這樣一個服務不能用了其他可以運作,但又不是拆越多越好,要點還有很多,放在講義裡,簡言之就是頭腦清楚了再上工。
程式必須在好的工具與工作習慣下,才能有彈性。以「logs all the time」為例,若已知道要寫log,卻沒有照標準格式寫,用 ELK會亂成一團,要有固定格式,ELK才抓得到。建議一開始規劃,測試人員就要進來了,一有規格就要寫測試項目與方法,原來就應是流程的一部分,用jenkins做測試自動化。用docker安裝配置,王大哥特別提醒大家,沒聽過docker的主管的公司不要去,因為主管不知道這個東西的價值,不會給你相對映的價值。最重要的是,做任何軟體一定要有簡化後的基本功能,趕快給客戶用去得到反饋,還沒用過之前,客戶有時也不知道要給什麼反饋。
補充:log
[Python] logging 幫你紀錄任何訊息 @ 工程的日子每天都很師 :: 痞客邦 ::

有把握(持續monitoring)

除了測試,還要持續監控,自動化測試固然是一定要的,講義中提到許多觀念與工具,也補充了log該如何寫。厚積薄發,是不變的基本精神。
補充:CICD
什麼是 CI / CD ?
架構師觀點: 你需要什麼樣的 CI / CD ?
我好奇地問我同學,DevOps後是否世界和平了,但最終還是得到「理想很豐滿,現實很骨感」的答案,他說:
「理想上沒錯,不過實際上要革命性的採用,對於已發展到一定規模的團隊和產業,反而非常不容易套用與轉換,光自動化測試或者持續整合,在環境複雜的產業錯綜複雜的系統以及流程,要導入實在非常多阻力與困難。」
我認為這些阻力與困難來自文化改變的緩慢,以及習慣帶來的虛幻安全感。
這週在線上參加Google Cloud的線上研討會「打造你的AI與機器學習技術力」,益發認為AI很可能成為新世代進入職場的標配,就像我們這個世代會使用word與excel,大廠也因此有很多研討會或課程,我的生活越來越豐富了。
分類:學習

評論
上一篇
  • Python Taiwan讀書會_13_UML
  • 下一篇
  • 更多文章
    載入中... 沒有更多了