在醫院擔任行政助理七年來，我經歷了許多職場挑戰與困惑，特別是在升遷和報酬方面，曾經有一段時間讓我感到十分失望。不過，隨著時間的推移，我學會了轉念，也找到了新的職業方向，逐步擴展自己的視野，並開始嘗試多元發展。

升遷與報酬的失落感

作為一名輕度弱視的身障者，這並未影響我對工作的熱情和努力。回想當初剛進職場時，我懷著滿滿的熱忱，積極參與各項工作和活動，並且努力爭取升遷機會。曾經擔任尾牙主持人，也辦過讀書會等，這些經歷讓我展現出主動性和對工作的熱情。然而，當我在等待升遷的過程中，發現自己的努力並未得到應有的回報時，我深感失落。尤其是在工作量逐年增加，但薪資卻沒有相應的提升時，這樣的情況讓我陷入了困惑與沮喪。

更多新聞：【學長姐帶路】2023 研替 AI 工程師 求職心得

無法得到應有回報的掙扎

在職場上，我漸漸意識到，單純依靠努力與實力，並不一定能換來升遷或相應的回報，尤其是作為契約人員，升遷機會本就有限。儘管我積極尋找機會並嘗試突破現狀，每次付出的努力後依然無法看到改變，這讓我不禁開始質疑是否應該繼續堅持在這個體系內，還是該尋求其他的職業方向。

多元職涯發展與轉型

儘管面對職場挑戰和困惑，我並未放棄對自己職業生涯的規劃。我學會了轉換心態，把焦點放在自己熱愛的事物上，並積極探索不同的發展機會。從參加讀書會、進行線上說書等活動開始，我發現這些興趣不僅擴展了我的視野，還讓我不再受限於傳統的工作框架。此外，我也開始嘗試斜槓發展，曾經擔任過標準化病人，利用自己的經驗來幫助醫學考核的學生，這不僅讓我發現了新的興趣，也找到了自我價值的更多層面。

重新調整生活重心

隨著年齡的增長，我漸漸認識到，生活和工作之間的平衡變得更加重要。無論是在職場中追求升遷還是報酬，都不應該成為唯一的焦點。我學會了如何將自己的精力分配到更多元的生活領域，並在工作與家庭之間找到更好的平衡。這樣的調整對我來說尤為重要，因為無論是在事業發展還是生活質感上，都需要找到一種平衡，才能擁有更全面的幸福感。

未來的展望：勇於探索更多可能性

這段經歷讓我更加深刻地理解到，不論是面對職場挑戰還是生活中的各種選擇，都需要勇於探索更多的可能性。作為一位過來人，我希望能夠鼓勵其他上班族，尤其是在面對困難時，要保持開放的心態，去尋找更多的發展機會。對於單身者，我建議可以更多地嘗試新的職業道路；而對於已經有家庭的人來說，也要懂得在家庭和事業之間找到屬於自己的平衡點。

這篇文章 【學長姊帶路】工作甘苦談：從職場低谷到多元發展！一位過來人的逆襲之路 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《#工作心得 2024/07 QSAN 廣盛科技股份有限公司 暑期實習心得》

文／DCARD 網友

為了完成學校的實習必修學分，且剛好有這個可以來到 QSAN 暑期實習的機會，而目前差不多滿一個月了，於是來寫一篇在 QSAN 實習的心得！

工作相關 💼 ：

工作內容📓：

在剛開始時有做過一個使用 Go 語言的 Error Parser，主要是利用 Golang 撰寫主要程式碼，再利用 SQL 建立資料庫。而目前在接觸與 NVM Express 相關的內容以及環境的建置（雖然建了兩周多還沒建好 :((）

工作環境🏢：

個人工作的地方其實算頗大的，而且環境也挺乾淨的，附近吃的其實不少，但口味就因人而異了～

工作氣氛🙂：

原本在想像中應該壓力會挺大，但實際上其實還好，只要有做出一點東西，有一點進度，就不太會有問題。但做不出來的話，有可能是因為我是脆弱玻璃心爛草莓廢廢的大學生，主管也不太會苛責，也會時常問有沒有遇到問題，有任何問題也都可以去問，基本上只要不要混就好。有時也會有其他的實習生同事來聊個天，整體上還算不會太壓抑

個人心得 💬：

在這一個月以來其實除了最基本的程式設計邏輯之外，學校教的東西都用不太到（也有可能是我沒學好），所以來到這裡除了工作之外更多的其實是學習，學習工作內容會需要的技術，學習研究更深的理論知識，裡面絕大部分或是說全部都是學校不會上也不可能會上的東西。所以我覺得來到 QSAN 是一件能夠學習到很多東西的機會

總結 😃：

QSAN 是一間軟韌體研發的公司，所以來這裡也是能學習到很多相關的知識，也是可以實際體驗軟韌體開發的過程的地方，如果對此相關內容有興趣的人，我算是蠻推薦來到 QSAN 實習的，會學到很多東西，真的很多，會是很充實的一段時間

※本文由 DCARD 網友 授權轉載, 原文:《#工作心得 2024/07 QSAN 廣盛科技股份有限公司 暑期實習心得》

這篇文章 【學長姊帶路】廣盛科技程式設計暑期實習心得 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《#面試心得 台積電技術員面試心得分享》

文/DCARD 網友

文長慎入，排版有點亂請見諒，面試前也是透過版友分享獲益良多，想回饋一下!

我自己是非本科系大學畢業，透過官網投履歷(有請認識的內推)，投完履歷期間幾乎每天都有上去更新履歷，但也是過了一個月左右才收到面試邀請，當天有收到兩個部門職缺邀請，一個是HR直接電話詢問面試意願還有確認面試時間，另一個部門則是簡訊詢問意願，所以我是選擇有電話直接通知的部門，面試時間是在一周後，確認面試後會收到mail，mail內會有英文題庫跟面試流程。 (收到邀請的職缺跟我一開始投的不同，我在猜可能我原本投的職缺已經招滿，因為後續我才在官網上看到有邀請我面試的職缺)

我是應徵南科職缺，面試當天先到櫃台報到交手機，進大廳就要關機，手機會收在信封內，信封上會寫號碼要記，離開時領取要報號碼。當天我有提早到，招募人員問我要不要先做適性測驗，適性測驗有分兩個部分，兩個測驗時間我個人覺得都蠻短的，其中一個我還壓秒完成，當下很緊張怕沒做完會不會影響後續面試，還好有在時間內完成，適性測驗我都是選正面一點的，這部分可以再參考其他版友分享。做完適性測驗後回到大廳休息區，測驗英文+數學，英文大概1.2個沒有在題庫內，數學就跟網路上分享得題型差不多就是改數字。 (面試服裝:長袖白襯衫+西裝褲+皮鞋，但當天我看蠻多人也都穿Tshirts而已)

完成英數測驗後就到裡面的等候區等主管面試，當天大約10個人，我看其他人都離開了剩我還在等候區，大約等了1.5小時才換我面試，面試我的是副理，沒有請我自我介紹就直接從履歷內開始詢問(建議還是要準備一下自我介紹)，大概是問怎麼沒有繼續之前的工作、為甚麼會想來應徵台積、知道這部門工作內容嗎、可以輪班嗎、穿無塵衣ok嗎、跟內推的人是甚麼關係，面試過程還算愉快，主管也有稍微跟我介紹工作內容，我也有主動問了不少問題(一定要主動提問)，面試時長大概30分鐘，出來後在等候區坐一下招募人員就來通知今日面試已結束，回去後約2~4週通知，現場也都沒其他人了，想說怎麼沒有人資二面，當天面試的人好像也都沒有，只能先回家等看看後續通知。

主管面試完的隔天，mail收到面試問卷滿意度+HR遠端面試邀請，上系統選了時間。預約一週後與人資遠端面試，也是一樣沒有請我自我介紹，從履歷的工作經歷一一開始詢問，會問工作內容和起訖時間，所以記得要查一下勞保記錄，我曾經有待業也有問待業期間在幹嘛、怎麼沒有繼續上一份工作、離職原因、工作上有沒有遇到甚麼挫折以及如何改善、怎麼會來應徵台積電、如果台積電沒上會尋找哪些工作、資歷查核的對象確認、何時能開始上班，面試時長約40分鐘，反而人資面試問得比我想像中還細，也問得比主管還多，而且都會從我的回答衍伸其他問題，比起上次主管面試，人資這部分更讓我緊張，最後記得還是要主動提一些問題，結束後就是等後續通知，我自己忘了問大概須等多久，看版上分享大約2~4週會有結果。

HR遠端面試後隔天一樣有收到滿意度調查，在這之後大概等了15個工作天都沒任何通知，因為真的等得很煎熬，所以我就主動寄mail給人資詢問面試進度，信件內容可以估狗或AI跑一下微調，我是有表明如果還在流程中會願意等待，可能才不會讓對方覺得過於著急，寄信詢問這部分就看個人，我看版上有人寄信後收到感謝函，但也是有人收到offer，所以就當作參考，我是因為真的認為等待時間有點長才寄mail詢問，神奇的是寄完mail隔天，就有另一位人資電話來跟我確認資料然後說會送簽給主管，大約等1~2週時間會在後續通知，最後就是等了6個工作天後收到offer。

(在收到offer之前，還有透過其他版友內推，2天後就馬上收到面試邀請，但在隔天就有人資打電話來說我還有一個面試未完成，所以沒辦法面試其他職缺要先取消，蠻好奇怎麼有人可以同時面試兩個職缺的)

以下簡略時間分享(只算工作天，假日不算):

D 投履歷

D+30 HR電詢面試意願*1 、簡訊面試意願*1

D+35 主管面試+廠測

D+36 收到HR遠端面試邀請

D+41 HR遠端面試

D+56 mail詢問HR面試進度

D+57 HR電話資料確認、詢問何時可報到、送簽

D+63 收到offer

最後只能說千萬不要待業時應徵神山，真的會等到心很累，除非是天選之人，祝福大家!

※本文由 DCARD 網友 授權勿任意轉載，原文《#面試心得 台積電技術員面試心得分享》

這篇文章 【學長姊帶路】台積電技術員面試心得 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《2024 求職與 QA 轉職心得》

文/Penny Li

如果對我的人生故事有興趣的人可以去看前一篇（職涯建議與赤裸的人生歷程分享），先簡單交代個人背景：

• 第一份工作在日商物流相關的公司工作，歷時2年10個月
• 半年待業狀態全心學習前端知識，結果先以 PM 身份進到軟體業，過了半年後內部轉職前端
• 成為前端5年多，技術能力自認大概只有 junior 偏 mid-level 的程度，後期能力成長比較偏向產品與商務邏輯實現的面向，評估自身狀況後決定轉職 QA

關於職涯發展又有一篇很棒的文章，許多內容也不限於軟體工程師的職涯反思，供大家參考：

• 反思系列 — 軟體工程師的價值、影響力與職涯發展 ｜莫力全 Kyle Mo

面試前的準備建議

由於個人是那種很容易緊張腦袋空白的那種（連講自我介紹都會緊張呢 orz），所以面試前先盡可能準備好自己想得到可能會被問的問題，先想好或是寫下來有助於真的面試時才能好好回答，至於履歷/面試的準備網路上有許多文章跟影片就不贅述了，總之履歷有做足功課並好好準備，通常都還是會有面試機會，每次面試完答不好的問題，都要結束後反省與思考怎麼回答得更好，面越多就會越順。

至於履歷跟 cover letter 是否需要客製化？我覺得看時間、個人勤勞程度、你多想上這間公司，由於我是轉職，履歷上可能沒那麼有相關經驗，就可以在 cover letter 說明求職動機與自己做了哪些準備與努力；有些公司會有自己的投遞管道，可能就附帶一些他們的問題，不一定需要準備 cover letter；我自己是針對 QA 職位準備自己比較有沾邊的經驗來寫，每家用相同履歷，cover letter 簡單說明自己的職涯目標跟了解程度，投遞時會根據職缺描述微調或不調整，基本上大同小異。履歷的重點在於能讓你拿到面試的入場券，能做到這點就足夠了。另外自傳也是可準備可不準備，有公司不會看有也公司很在意，但是多準備是不會扣分的。

另外就是投遞管道，公司為了職缺曝光通常會在不同求職平台刊登職缺，但是如果要能更容易被看見，可以去公司官網看看有沒有更直接的投遞方式，例如：官方提供的投遞管道、人資信箱、官網直接連結到的求職平台等等。當然最有效的方式，還是公司內部有認識的人直接幫你內推。

如何了解公司？PTT、求職天眼通、GoodJob 職場透明化運動、面試趣、看看官網、找找新聞、問認識的人，你想得到能獲得進一步資訊的都可以試看看。面試如果是線上會議，會看到參與的面試官名字的話，也可以去 LinkedIn 搜尋看看面試官大概是什麼職位、有什麼經歷，推測可能會被問的問題面向，LinkedIn 還滿容易搜尋到的。

求職的策略

先在 Cake 找有興趣的公司投遞一輪
→ 在 Yourator 找有興趣的公司投遞一輪
→ 在人力銀行找有興趣的公司投遞一輪
→ 還是沒辦法的話等 QA 的課程上完，知識點補差不多再調整履歷投遞一輪
→ 還是沒有的話往自己稀薄的人脈找看看

由於在 Cake 這一輪就拿到喜歡的 offer，就沒有照後面規劃的繼續投，總共投遞12家，有後續聯繫或進入下一關共4家。從5月中開始投遞，7月下旬拿到 offer，歷時約2個月多，中間6月還有跟家人去日本玩，因為是在職找再加上轉職，會看職缺要求找可能比較能接受無經驗的職缺，沒有進行海投，因此是一週投個5、6家，等待進一步消息或面試，這一輪差不多後再投下一輪5、6家，而且不確定這件事會持續進行多久，就按照自己的步調邊面邊學習。

核心技術有限公司 — 網頁測試工程師 | Web QA Engineer

投遞方式：在官網招募頁面有公司投遞的 email 直接寄履歷

面試流程：HR Phone Call → Onsite Interview → 結果通知

結果：感謝信（主動告知）

日商接案公司，案源主要來自日本，因此 spec 會以日文來寫，雖然公司有翻譯人員但鼓勵大家學日文，會有日文津貼。辦公室在 101 大樓，面試趣 QA 分享整體的評價不太高，全中文面試。另外就是辦公室真的是頗安靜的 XD

投遞後 HR 會先以 email 約電話訪談時間(約15~20分鐘)，電話訪談後有下一階實體面試也會以 email 約時間。實體面試 HR 會先拿一份性向測驗與邏輯測驗題目給你，作答時間約20分鐘，題目不會很難。寫完後 HR 與 QA Lead 會一起進行面試約一小時。不論是否錄取都會通知結果。

面試心得：

HR 電話訪談時請你簡單自我介紹，基本上大概詢問求職動機，了解過去的經歷、轉職原因以及對未來規劃，為什麼會投他們公司，電話後面還有問前端三本柱分別是什麼個別的作用，其實心中有點三條線，我都當前端這麼久了竟然問我這種問題XD……不過想想算了 HR 嘛，又不是技術職，可能被要求先利用這種問題篩掉對於網頁測試完全沒概念的人，避免下一關浪費時間(?

因為有先瞄了面試趣的心得，先預備好 QA Lead 講話可能很不客氣的心理準備，但實際面試的感受沒有面試趣分享的那麼糟，雖然嚴肅但感覺就只是比較不擅言詞、講話會比較簡短而直接，是會認真做事做比說還多的那種人，被我自己歸為同類人（誤

QA Lead 會針對你的履歷內容問實務經驗而且問滿細的，因為是我的第一場面試準備的還不太足，履歷內容的有些問題回答得有點鬼打牆，非履歷問到比較 general 的專業知識與概念都算比較有回答出來。

HR 問的問題可能會部分跟電話訪談重複，有被問到一些還沒仔細想過但可以先準備的問題，例如：你認為什麼是好的測試流程？你找公司最看重的三個點是什麼？

在最後會有給你提問的環節，感覺是問到你自己說問差不多了才停。測試仍以手動為主、自動化為輔，issue tracking 使用 Redmine，自動化測試工具有搭配 Playwright、Puppeteer、CodeceptJS 等，提問完會以 HR 說明公司的福利制度作結，以及問你的期望薪資，談年薪並以14個月計算。

整體面試感受並不差，HR 跟 QA Lead 都很有禮貌，只是面試過程感覺比較像是一問一答沒有交流的感覺，這一點就比較可惜了。

Omnichat —自動化測試工程師｜Automation QA Engineer

投遞方式：在求職網站投遞

面試流程：HR Phone Call → Onsite QA Lead Interview → (可能) Onsite Product Manager Interview → ？

結果：只到 QA Lead Interview ，感謝信（自行寄信詢問 HR 後回覆）

Omnichat 全通路科技是一間香港老新創公司（面試的 QA Lead 這麼稱呼，公司是新創風格但是成立也有一段時間了），產品在做的是全通路對話式商務，從整合不同通訊渠道一站式處理顧客訊息起家，漸漸延伸到用戶數據追蹤、行銷等方面。公司在馬偕醫院附近，不過據說快坐不下了公司有打算要搬家。

原本投遞的時候是投「測試工程師 | QA Engineer」，依職缺描述比較是著重在手動測試的部分，HR 電話聯繫時告知該職缺有找到人了，與 QA 相關的職缺還有「客戶技術支援工程師｜Customer Service Engineer (QA)」、「自動化測試工程師｜Automation QA Engineer」，前者是歸屬在客服部門，是公司第一個更專注於技術導向的客戶支援角色，但也會參與測試，比較著重在 Bug 追蹤與解決；後者與原本投遞的職缺都歸屬在 QA 團隊，不過 Automation QA Engineer 工作內容就會明顯是與自動化測試相關的佔比較多。

面試心得：

投遞後 HR 先在 Cake 上丟訊息，會問你是否有方便聯繫的時間，給了後並不會跟你約確定的時間，只能自己那個時間待命做好會突然接到電話的心理準備，也可能因為是臨時的電話聯繫，只有簡單問你求職的動機、了解你目前 QA 相關的能力與掌握到哪，簡單交流一下上面提到的另外2個職缺狀況，以及我對哪個職缺比較感興趣，因為我說對 Automation QA Engineer 比較感興趣，因此後續是跟 QA 團隊主管面試。

那時候是6月面試，QA Lead 5月才進來 Omnichat，所以 QA 團隊成員待在公司的時間比主管還長，不過感覺得出來 QA Lead 是個很有能力的人、而且還比我年輕(28歲)，投入職場以來就一直是在 QA 領域了，並且正在蓋公司自動化測試的基礎架構，想要再找2個 Automation QA 進來，看重態度更勝於能力方面。

面試先從自我介紹開始，並且也一開始就告知我，他可能會根據內容有感興趣的地方就問問題而打斷我，面試過程也會很 free style 像聊天一樣。不過可能我實在是太容易緊張了，自我介紹講一講他就叫我放輕鬆一點不要緊張，希望我能展現出的是更接近工作狀態、不是那麼緊繃的樣子，盡量展現自信的樣子。（可以的話我當然也想 XD）面試尾聲我有詢問有沒有什麼給我的改善建議，不擅言詞的部分建議我去多多面試，說他以前也是這樣（？）多面一點就會變好，而且鼓勵我保持在可以一直去面試的狀態，以主管的角度給出這樣的建議還滿少見的。

從 HR 電話約面試到實際面試，中間卡了跟家人出國玩，原本想說這段時間還滿長的，好像可以稍微補一點自動化測試的東西，面試前還先詢問了團隊使用的框架是什麼(Playwright、Jest)，結果後來還是沒時間準備這塊，感覺導致讓 QA Lead 期望拉太高了，原本他有想問 Playwright 的問題結果也沒辦法問，整個失策。

面試時被問了一些我覺得也很重要的想法或觀念問題，例如：你覺得為什麼需要有 QA 這樣的角色？ PM、RD 都可以自己測為什麼還需要 QA？QA 的價值是什麼？為什麼需要自動化測試？手動測試就可以做到的事情為什麼還需要自動化？有些我被問之前還沒仔細想過。確實，搞清楚 QA 角色做的事情帶來的價值是什麼，你才有可能把工作做得更好、把價值極大化。另外也有舉一些實際工作會遇到的狀況，請我說明會怎麼進行，不知道時不是因為沒有實務經驗，回答好像沒有很打中面試官想聽到的答案。

另外中間聊一聊就突然出了一個情境白板題，雖然不難也大概知道方向，不知道是不是因為第一次遇到白板題的關係，總之在概念上轉換到 code 的時候一直卡卡的，搞得2個人都有點灰心，跟面試官的溝通也不太順暢，後來還實際用他的電腦開產品的頁面，直接在 dev tool 寫 code，但我感覺已經慌了還是沒寫出來 XD（後來回家有自己實作並在感謝信提供）。後面就是補問了一些人資想問的問題、看看我有沒有想問的問題收尾。

雖然沒有錄取，但在這場面試學習到了很多，也讓我在後續的面試調整了回答的思考方向，對我來說是一場獲益良多的面試。

OneDegree — Software QA Engineer

投遞方式：在求職網站職缺頁面上，OneDegree 提供的連結投遞

面試流程：HR Phone Interview (1 hour) → Onsite Interview

結果：只到 HR Phone Interview ，感謝信（主動告知）

OneDegree 是個還滿有名氣的公司，許多前端大神待過，網路上也有滿多公司的資訊，產品從保險數位化開始做，但現在也有一些不一樣面向的產品，可自行多查詢就不贅述了。投遞後 HR 會寄信聯絡請你給可以 Phone Interview 時間，Phone Interview 有預告約1~2週會通知後續結果，然後真的隔了整整2週我才收到感謝信。跟 HR 要聊到1小時是真的滿久的，會先由人資介紹公司部門及 QA 團隊的現況，再來就會環繞在個人經歷及價值觀等等的 culture fit，也可能我的經歷不多，每個經歷都被問了工作狀況以及離職原因，我覺得問的還滿細的，感覺得出 OneDegree 在人資這關就花了滿多的努力去找適合公司的人，可惜沒有進到下一關 QA 面試的環節。

Mammoth Cyber — 手動軟體測試工程師｜Manual QA Engineer

投遞方式：在求職網站投遞

面試流程：Online Interview(QA Team、QA Lead) → Online CEO Interview

結果：offer get

Mammoth Cyber CEO 是台灣人，在美國創立公司，產品是企業瀏覽器，屬於資安領域比較新興的解決方案。投遞後 HR 先電話聯絡，簡單說明有收到履歷並且會在 Cake 上約時間面試，後續大部分跟 HR 聯繫也都是透過 Cake 訊息，並預告第一階段面試會大概花3小時，第一次要花這麼長的連續時間面試，覺得硬 XD

面試過程都是使用 Teams 線上會議，第一階段面試3小時分成2個部分，前半先跟2位資深 QA 面試加上 live QA/技術測，後半則是跟單獨跟 QA Lead 面試。隔2週後與 CEO 面試並談 offer。

另外奇妙的是面試趣只有一篇 QA 的面試分享，評價不太好，跟我實際面試的情境與感受完全不一樣，所以說還是自己實際去面試來得準。

面試心得：

第一階段面試一開始會由2位 QA 面試官說明面試的流程，並且先以 QA 情境/技術題目開始，題目以 Google 文件提供，並且需分享畫面進行答題，答題時可以使用任何平常工作時你會使用的工具例如 chatGPT、google 搜尋等等，只是進行任何操作都必須在分享的畫面上。

題目有三題分別為不同面向：給你功能請你寫出 test case、根據測試情境寫出自動化框架的 code、LeetCode 約 easy — medium 的題目。後2題有程式碼的部分則在 codeshare 上進行 。過程有任何不懂或問題面試官也很願意幫忙，面試過程著重在的你想法及思路而非考倒你，老實說是個很不錯的面試體驗，也很接近工作時你真的會利用什麼去完成你的任務。專業/技術的部分結束後，就是自我介紹以及經歷、經驗、工作內容的交流，以及讓你問問題。

QA 團隊成員面完後他們會離開視訊會議，等 QA Lead 進來同個會議裡，問題也是個人經歷上的交流，還有一些人格特質的了解，掌握你對於 QA 工作內容的了解程度以及相關經驗。也有介紹一下團隊工作流程，公司產品可能會觸及的測試面向等等。

當天面試從 9:30 一路到 13:00，下午還接著工作，快下班時整個疲累感上來，幾乎快無法思考。吃晚餐時連看動畫的餘裕都沒有，只想讓腦袋放空，靜靜地播著芙莉蓮的片尾曲 Anytime Anywhere 邊吃著晚餐，聽著聽著想起了艾冉的經典名句「努力過的人都是戰士」，這句話就像是有人溫柔地摸著你的頭，說：你很努力了呢！當覺得自己已經盡了最大的努力後，這句話真的很有感觸！不管結果如何，我已經盡我所能了。

試，原本約了下一週面試，不過好像剛好 CEO 有一些行程的調整，才多延了一個禮拜。跟 CEO 面試時間是早上8:00，原本以為 CEO 人在美國這個時間滿合理的，結果面試時他其實暫時飛回台灣了。簡單聊了一下為什麼想來公司及做 QA，公司的產品及產業發展以及談談 offer。CEO 也給了一些關於職涯選擇很棒的建議：產業選擇與成長機會應該要優先考量，並且要對自己的選擇有熱情。

雖然面的沒有特別多，不過還是想好好紀錄一下這次的面試過程，很慶幸沒有花太長的時間就找到了這次求職自己理想的工作。另外不確定是不是因為是轉職的關係？註冊與登入是個還滿 general 大家都可以想像到的功能與情境，是面試滿頻繁出的測試情境考題，所以可能可以在這方面做更細的準備（測試如何規劃、test case 怎麼寫等等）。

搞清楚為什麼自己想做 QA、並確實去了解工作內容，不會跟自己想像的落差太大，堅定地朝著自己的目標努力，相信轉職只是時間早晚的問題。跟原本公司提離職要轉換領域時，當時主管給的評語：「可以理解你為什麼會想往 QA 發展，如果有大家已經先達成共識怎麼處理的事情，有人沒有照講好的方式做時，你會比較生氣；但如果是沒有被討論過的部分發生問題時，你就會比較還好，再看是要補文件還是怎麼處理再一起討論就好。」這個評價還滿有趣，是有符合我對自己的認知沒錯，不過感覺大多數的人也都是這樣（？

※本文由 Penny Li 授權勿任意轉載，原文《2024 求職與 QA 轉職心得》

這篇文章 【學長姊帶路】2024 多間 QA 工程師 面試心得 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《#工作心得 【2024 Intern】崛智科技 - 數位IC設計工程師》 

文/DCARD 網友

大家好~我是今年數位IC工程師實習生Shawn，這兩個月的實習終於結束啦~

首先感謝ICA部門的戰友Ian & Alan，陪我天馬行空的討論工作內容，還有一起掃盪零食吧XD

然後要特別感謝我們的導師Michael，會在每週兩次的會議上幫我們上課，還會關心我們生活過得如何，超級用心，我超感動的啦~

還要感謝MLD部門的River & Andy，除了教會我許多工具的使用，還會在我快想破頭的時候說一些幹話讓我放鬆，非常給力XD

最後感謝崛智的其他夥伴，中午的時候都是揪團買飯，給了我溫馨又充實的暑假，還有很多想說的話沒辦法只用三言兩語表達，因此希望透過我的這篇心得分享能夠讓更多的學弟妹加入崛智這個大家庭親自體會。

我的背景是中字輩理工學、四大電資碩一，有把數位相關的課程都修一修，碩論是數位的架構設計，並且有一次AI加速器的下線經驗，成績不算太好，應該很多人都有比我好的學經歷。

那以下就進入正題，分享一下公司資訊以及面試的過程：

公司名稱：崛智科技(DigWise Tech.)簡稱DW

工作地點：竹北昌益園區B棟8樓，離火車站走路只要十分鐘左右，很新的園區，餐廳是網美打卡聖地

面試時程：

D 投遞人力銀行履歷，公司當天就讀取

D+ 2 一面邀請

D+14 一面(執行長)、二面邀請

D+20 二面(單位主管)

D+22 三面邀請

D+23 三面(人資)、offer get

面試內容：

面試都是遠距進行，時間也很彈性，人資會開幾個時間讓你選擇。

一面的時候還沒什麼經驗，就大致放了在學校做過的一些專案以及覺得關聯性比較高的作業，結果看到是執行長下來面試差點嚇死，講的時候腦袋當機了幾次，不過幸好執行長人很好，大多是在聊天，沒有問什麼艱難的問題，還說我聽起來對這個領域很有熱誠XD，最後說覺得我滿適合ICA部門的，會再把我的履歷轉給部門主管。

二面就是ICA的主管來進行面試，主管面試時給我的感覺很嚴肅，在我講的時候都沒有說話，結束以後會要我翻回去特定的頁面然後問一些細節，包含一些課程的內容，我覺得回答得不是很好，但主管說我會得滿廣的，然後就開始介紹這次實習的計畫安排，最後說保持聯絡，會再請人資通知結果。

過兩天以後收到錄取通知，並安排第三次面試，第三次面試只是跟人資聊一聊天而已，有住宿或是交通等等的問題都可以在這時侯提出，面談結束後會寄入職文件來簽名。

錄取單位：智能晶片架構部門(Intelligence Chip Architecture, ICA)

工作概述：

這邊是彈性工時、不加班。 實習期間主要是協助開發AI晶片的專案，也許這邊不是大家常說的一線廠，但是比起打雜，能讓自己的履歷增加核心的開發經驗更重要。入職一開始開會的時候主管會說明這個專案的整體方向，讓大家釐清要做的東西是什麼，之後會根據每個人的經歷來分配適合的工作，像我是負責PE的設計。導師給了我們很大的創作自由，把設計過的架構拿過去他都會認真跟你討論優缺點跟潛在的問題，還會分享一些paper提供參考，就這樣一步一步改良成理想的設計，架構沒問題了之後就會進行元件的設計，雖然公司已經有專門負責這些IP的部門，但是作為雛型的Demo與結果驗證上的方便，子電路也需要自己用Verilog寫出來，例如FP32的乘、加法器等等，並為每一個模組寫一支Python來產生測資以確保這個設計是沒有問題的，理所當然地，子元件都驗證完成後，組合而成的Top模組也需要再產生測資做一次驗證，就這樣一層一層往上完成這個PE的設計。

工作和學校最大的差別，除了專案的規模外，最重要的是設計的可讀性與交接的準備，一個專案可能會有很多個人同時、甚至不同時協作，你也需要研讀上一個人留下來的資料，因此註解要寫完善，排版與可讀性要做好，設計完成後還要花時間寫README才算是完成整個模組的設計，不像以往在學校只要Code寫完能動就可以交作業了。

另一個比較特別的是每週的會議，要做簡報來匯報進度，這些簡報不只是當下拿來呈現，更是之後會留下來做參考的內容，所以要寫得夠詳細，但也不需要太有壓力，期間可以把遇到的問題講出來，讓大家一起討論。

公司環境：

OK終於到了我最愛的環節了，這邊要來分享一下公司乃至園區的環境，首先是公司裡面有零食吧可以吃到飽，飲料有必備的快樂水、波蜜甚至還有午後紅茶，零食多到數不清，基本上你在全聯會看到的都會出現，每週都有可能不一樣，所以我都會在禮拜一去掃蕩一波，吃爆！另外還有咖啡機，記得要帶馬克杯去裝。然後辦公環境是開放式的桌椅，對桌跟後面都會有同事陪你一起工作，遇到困難就一起討論，絕對不會寂寞。

園區餐廳就在公司那棟樓的左邊，走路很快就到了，一樓是明亮的落地窗，視野很好，可以直接看見整個園區，我最愛的是90元裝到飽的自助餐，每次都裝一大坨白飯淋上滷汁，吃得好爽，吃膩了的話還有健康餐盒、八方雲集、韓式便當、蔬菜捲跟711可以選擇，然後不定時會有外面的餐車來擺攤。

最作一下總結，在這裡你可以：

- 學習成為一名合格的Designer

- WLB - 練習口語表達與簡報製作

- 認識很多人脈、朋友

- 零食吃到飽

如果你像我一樣想體驗一下業界的生活，非常推薦大家來DW實習，我的分享就到這邊，有什麼問題都可以問我唷~

※本文由 DCARＤ 網友 授權勿任意轉載，原文《#工作心得 【2024 Intern】崛智科技 - 數位IC設計工程師》 

這篇文章 【學長姊帶路】崛智科技 數位 IC 設計工程師 實習求職心得 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《【軟韌體】2024面試心得分享》 

文/DCARD 網友

* 08/29 更：距離最後一間QNAP剛好過2個星期（08/12至更新當下），沒有任何通知，無聲卡。

【學歷背景】

學歷：混血中字通訊碩畢

專題：Arduino結合IOT設備

碩論：純通訊模擬

經驗：無比賽經驗、無實習經驗

成績：大學普、碩班中上

N = 2024 GG新人價

【前言】

我是從2023年8月畢業後，一直等到12月才去當兵，今年2024年3月底才退伍，而面試從4月中陸陸續續開始投遞。 面試的公司間數有12間，但投遞的公司都在南部居多(由於我是北部人，女友是南部人，有協調好是說不想要遠距離，所以就是我下去找工作這樣)，這邊要先講結論，如果真的沒有一開始就一定要在南部工作的理由，真的不推薦，會找得很辛苦。

面試過程非常累且煎熬，特別是不知道後面有更好的公司邀約或是沒邀約時，真的都很煎熬。這中間甚至想要去一間4Xk先做著來了，不然會在這個寒冬被凍死在路邊(我就是雜魚🥹)，所幸這間公司後來給我感謝函，才有機會上岸最想要的公司！

建議新鮮人可以多多用面試練習，提升自己的信心，先面試3-5家的小公司，累積面試經驗，當隨著面試次數多了之後，可以漸進式的改進自己的談吐及遇到的問題如何答覆，到後面面到8家以上之後就可以從容應對主管或人資所提出的問題。 小弟弟我自認雜魚，有感受到2024科技寒冬，差點失溫凍死在路邊。秉持著吸引力法則，自信真的很重要💪，自然機運就會來找你！

【面試前準備】

LeetCode：退伍後才開始寫的，但刷的題目不多，大概只有約20題左右的Leetcode(難度都是easy，用C刷為主)，有些我覺得是medium等級的，真的想不出來就去參考解答，然後再自己用自己的想法去做修改，這樣對我來說進步蠻多的，到後面大概就知道要怎麼下手。

考古題：準備網路上的軟韌考古題，例：0x10韌體工程師考題、前輩們的面試心得中的考題、實驗室學長和同學留下來的面試題......等等，一定要懂且必考的，bitwise、pointer、function swap、define、macro、union、struct、const、continue和break的判斷、六大排序法，就都是很基本的東西，只是要很熟練地知道怎麼去應用。

OCW：資料結構、計算機組織、作業系統，基本上我是通訊相關畢業的，只碰過資料結構，後面2科在看的時候，花很多時間在建立基本知識，念得很辛苦，到後面就只看資料結構了xDD。

過往實作經驗：像數位信號處理、數位影像處理都是通訊必修的課程，有稍微回去複習一下內容，另外像FPGA、MCU、Arduino都是大學有接觸過的，也有再去熟悉摸索過，這些都是在面試中會被問到的，想知道你到底會什麼。

【公司面試及心得】

1. 公司：瑞傳科技

職位：BIOS工程師

面試型態：實體

地點：高雄 面試過程：1張基本資料，1張C的專業測驗，考得還算簡單，都是給你一段程式問輸出，還有關於BIOS的一些基本知識，主管面談環節就是稍微檢討一下剛剛的專業測驗，然後問你對BIOS的了解，簡單介紹一下環境及工作內容。

結果：感謝函

2. 公司：泓格科技

職位：韌體研發工程師

面試型態：實體

地點：高雄

面試過程：這間是做工業自動化設備的，與第1間在同一天面試，一1張基本資料填寫，1張專業結合邏輯測驗、整體來說一樣不難，問程式的輸出、指標的應用、print出乘法表，還有寫一段英文自我介紹xDD，主管面談的話就是問一些修課上的內容，你碰過的MCU，實作過程以及架設的平台是什麼，最後就是介紹工作內容及環境。 結果：感謝函(理由想找助理工程師xDD)

3. 公司：新盛力科技

職位：軟體研發工程師

面試型態：實體 地點：高雄(面試在汐止)

面試過程：這間是做鋰電池相關設備的，整個面試過程的體感上很壓抑，是所有面試中讓我感到最不舒服的一次面試，想知道過程再私訊我。

結果：當場感謝函

4. 公司：瑞鑑航太科技

職位：通訊系統工程師

面試型態：線上

地點：臺南

面試過程：一面是面人資，先寫30分鐘的數學暨邏輯測驗，是英文命題，但題目不難，算蠻有趣的，但就是都要先思考過，所以時間上寫的有點趕，接著是英聽測驗，給你聽一段約15分鐘的對話，人資面談最後會問你故事的大綱是什麼，結局是開放式的，要你講出你會怎麼繼續往下寫。

人資面談就是自我介紹，問一些社團經驗，人格特質等等，最後結束時有說會把今天面試過程提供給主管，一個星期內會有結果，有過一面才會進二面和主管對談。

結果：感謝函

5. 公司：星博電子

職位：韌體工程師

面試型態：實體

地點：高雄

面試過程：這間是做馬達設備的，一1張基本資料填寫，1張邏輯測驗，1張專業測驗考3題，分別為馬達驅動方塊圖、浮點數和定點數運算的差別以及將類比控制系統方塊圖用離散和連續傅立葉設計轉換成數位控制方塊圖，邏輯測驗有些看到會會心一笑，例如：數大概有幾顆豆子、1-200裡面少的數字有哪些、1公尺等於幾公分等等🤣。

主管面試就是聽報告，然後提出問題，專題、碩論以及修課都要準備好，會問的蠻細的，接下來就是介紹工作內容以及工作環境及福利。

結果：感謝函

6. 公司：GG

職位：廠務工程師

面試型態：實體

地點：南科

面試過程：GG原本我只有丟IT，但不知道為什麼會被找去面廠務哈哈哈，但我那時候也一間都沒上，想說就去試試看吧，至少給的薪資不錯。 面試過程就是板上說的那些，一開始會做適性測驗，就誠實作答就好，但不要前後回答矛盾，再來就是英文測驗，本人英文很爛...但也很努力在聽懂題目在問什麼，只是作答有點長，到後面有點恍神。

主管面試就是請我簡單地口頭自我介紹，主管比較在意的部分就是社團與他人的合作經驗，遇到紛爭怎麼處理的，或是在社團中扮演什麼角色，然後問到說我是通訊畢業的加上都是應徵軟韌體，怎麼會想要應邀來面試廠務這個職位，我似乎回答得不好，主管一直圍繞在這上面提出問題😂，最後就是QA環節這樣。

結果：感謝函

7. 公司：宇曜智能(合勤內部獨立出來)

職位：嵌入式系統工程師

面試型態：實體

地點：新竹

面試過程：這間是主動找我去面試的，然後是做IOT相關設備的，會來面是因為一直收感謝函，心情上有點受影響，想說不然就試試看，有上再來考慮後續的問題，面試過程完全沒有筆試，直接進入報告做自我介紹，過程中介紹到人格特質，主管希望我能舉實際例子，因為他說聽太多人都說人格特質有哪些，但也不確定是不是真的是這樣xDD，後面在報碩論的時候，他有給建議說，我已經講得很清楚明白了，希望可以再解釋得簡單點，畢竟不是每個人都懂你的專業，後面就介紹工作內容以及工作環境，有問我說會什麼程式語言和接觸過哪些MCU且如何操作。

整體面下來感覺不錯，主管是很用心在聽報告，最重要的是有給回饋，讓我受益良多。

結果：婉拒，有接到意願電話，還是想試試看南部的工作機會(被肯定的感覺真的很好！🤩)

8. 公司：直得科技

職位：韌體/治具工程師

面試型態：線上

地點：臺南 面試過程：這間是​做馬達設備相關的，超多東西要寫，1份基本資料、1份人員問卷、1份數學暨邏輯測驗和1份專業測驗，邏輯測驗很簡單，其中有一題就是網路上流傳的徒手寫1-200😂，專業測驗的話，有5題，分別為敘述馬達控制的想法、嵌入式系統啟動的流程、使用過的MCU及如何操作、示波器抓取訊號要注意的地方和C語言中陣列和指標的差別。

主管面試環節就是直接用報告來自我介紹，結束之後會對你所報告的內容作提問，比較著重在專題以及碩論，後面就是介紹工作內容及環境，最後就是QA時間。

結果：感謝函

9. 公司：海邊

職位：電動車控制系統工程師

面試型態：線上

地點：高雄

面試過程：​一開始主管隨機抽考一題Leetcode，難度是easy等級的，然後要開螢幕分享，是沒有限時，中間對題目有疑問也可以發問，後面作答完之後，主管會和你討論怎麼寫可以更好，然後就進入面談時間，自我介紹報告完畢之後，主管就直接開始介紹工作內容以及工作環境，錄取的話會先到新店去受訓3個月，再派回高雄工作，然後會接觸到什麼程式語言這樣，最後就是QA環節結束，後續有另外一個部門的主管也有來面談，問我的經歷，有接觸過程式，然後再更詳細地介紹工作內容。

比較特別的是QA環節，我有主動詢問說：「剛剛報告哪裡需要加強嗎？因為看主管您好像沒什麼興趣。」，主管表示很訝異，我會問這個問題，因為通常都不會有人會這樣問，後來主管表示因為你做的東西跟我們沒什麼太大的關係，所以才沒有多作提問。後來我就有修改報告呈現的方式，都會把我會的跟我做過的東西和應徵職務做連結，也很感謝主管願意分享他的想法讓我知道。

結果：感謝函

10. 公司：鼎王

職位：觸控演算法工程師 面

試型態：實體

地點：臺南(竹科面試)

面試過程：這是面的第1間豬屎屋，所以準備的很認真，有種終於被看見的感覺(並沒有xDD)，一開始就是考40分鐘的專業測驗，題目包含不用除號做浮點數除法、給一段程式問輸出、問static在函式內的作用以及4大題的觸控相關考題，能寫就盡量寫，主管只是想看個人的思考邏輯，以及你對於觸控的想法闡述。

主管面談一開始就問我的104適性測驗中的正向積極為何分數很低，我整個很意外，畢竟我不是這樣的人，身邊的家人朋友從沒有這樣說過我，反正後來有用一些例子跟主管解釋說我這個人的人格特質，接著就是一樣先報告，然後對你研究過程問得很詳細，想知道是怎麼處理問題的，有沒有獨立思考並解決的能力，很注重在發現問題的「根源」並解決，後面就是介紹工作內容及環境，如果有面上可以選擇在新竹或臺南工作，然後要一面有過才會有後續處長那邊的二面。 後來都有追進度，寄信詢問人資多次，只有中間1次表示說主管還在面試其他人，希望可以再耐心等待，的確我看公司網站上的面試進度是還在審核中。

結果：面試結果審核中(應該算無聲卡)

11. 公司：捷達創新(天鈺子公司)

職位：觸控演算法開發工程師

面試型態：線上

地點：臺南

面試過程：一開始就是人資來請我先寫專業測驗，總共16題，內容大概就是問輸出、然後macro、#define、pointer的應用、bitwise、邏輯閘問輸出以及給電路問輸出電壓和電流是多少這樣，專業測驗結束之後就是主管面談，總共有4個部門的主管面談，報告完畢之後會針對個人的修課內容、專題以及碩論做提問，而且會一頁一頁地問，所以對於放上去的東西要非常熟悉，其中主管對我碩班修過一門課的程式作業很感興趣，有特別詢問說整個演算法的架構以及內容，還有碩論的整體架構是如何發想的？所採取的演算法策略是什麼？為什麼想要用這個方法？反正就是想知道你的思考方式這樣，後面就是介紹工作內容以及工作環境，最後就是QA時間。

這邊想特別提一下後續人資詢問意願、介紹薪資福利以及核薪的部份，對談過程都很舒服，有什麼問題都可以馬上做提問，也很有耐心的解釋，態度非常客氣。

結果：Offer Get (N + 1xk) * 14

12. 公司：QNAP

職位：軟體研發工程師

面試型態：實體

地點：高雄

面試過程：一開始就是人資來請我先寫1張邏輯測驗約40分鐘，題目很有趣，還蠻燒腦的，有興趣的可以再私訊我，接著就是30分鐘的專業測驗，題目也都不難，也都是給一段程式然後問輸出，pointer也考蠻多的，可以多練習相關題目。

主管面談是有2位，一樣是自我介紹報告完之後，會針對你的修課內容、專題和碩論做提問，問的沒有很刁鑽，有準備一定都可以回答，然後就是介紹工作內容以及工作環境，所會碰到的平台是什麼，例如：Linux，基本上也都是用C去寫這樣，最後就是QA環節。結束之後會換另一個主管來考白板題，難度是easy等級的，中間不懂題目或是詢問提示都可以，最後花了一段時間才寫出來，因為是第一次實體白板題，會有些緊張，但LeetCode刷得夠多應該會很快就解得出來。

結果：等待中（2星期無任何通知，無聲卡）

以上就是我這4個月的面試歷程，取之於版上的資源，現在換我來回饋給後續面試的新鮮人也好，轉換跑道的也好，都希望可以多多少少幫助到大家。這邊也想說面試過程真的很艱辛，特別是等待的時間很煎熬，只要聽到手機震動或通知就會很緊張的想是不是結果通知，但我覺得最重要的是要有自信！要有自信！要有自信！因為你都不相信你自己了，還有誰可以相信你？有時候不是自己不夠好，而是時機還沒到，像我就覺得我運氣很好，要不是前面一系列的感謝函，我也不會拿到想要的offer，所以請大家繼續要堅持、不要放棄，跟身邊朋友一起努力，互相砥礪，到後面就會越來越上手的，最後就是祝福版上的各位，都可以找到自己理想中的工作，加油！

有任何問題都可以透過私訊問我喔，謝謝大家☺️

「有時候不是不夠努力，只是努力得不夠久。」共勉之🤣

※本文由 DCARD 網友 授權勿任意轉載，原文《【軟韌體】2024面試心得分享》

這篇文章 【學長姊帶路】瑞傳/泓格/瑞鑑航太/星博電子 等多間工程師求職心得 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《IaC Part 11 -Building Servers as Code》

文/運用雲端服務加速企業數位轉型

IaC最初是作為配置伺服器的一種方式出現的。 系統管理員編寫 shell、batch和 Perl scripts。 CFEngine 率先使用宣告式、冪等(idempotent) DSL 來安裝套件和管理伺服器上的設定文件，CHEF和Puppet也隨後出現。 這些工具假設是我們有既存伺服器 — — 通常是機架中的實體機，有時是使用 VMware 的VM，後來是Cloud Instance。

現在，我們要嘛專注於Infra stack，其中伺服器只是一部分，要嘛我們使用Container cluster，其中伺服器是其底層架構。

但伺服器仍然是大多數Application runtime環境的重要組成部分。 大多數已經存在多年的系統至少在伺服器上運行一些應用程式。 即使是運行cluster的團隊通常也需要為host node建置和運行伺服器。

伺服器比其他類型的基礎設施（例如網路和儲存）更複雜。 它們有更多的移動部件和變化，因此大多數系統團隊仍然花費大量時間陷在作業系統、軟體包和設定檔中。

本文介紹了以代碼形式建置和管理伺服器配置的方法。 它從伺服器的內容（需要配置的內容）和伺服器生命週期（配置活動發生時）開始。 然後轉向伺服器配置代碼和工具的視圖。 本文的主要內容著重於建立server insatnce的不同方法、如何預先建置伺服器以便可以建立多個一致性的instance，以及在整個伺服器生命週期中應用伺服器配置的方法。

下圖將伺服器的生命週期視為具有多個過渡階段，這樣的作法對我們管理伺服器會很有幫助。

上圖顯示的基本生命週期有三個過渡階段：

1. 建立並配置server instance
2. 更改現有server instance
3. 刪除server instance

本文介紹建立和配置伺服器。 Part 12介紹如何對伺服器進行便更，Part 13討論建立和更新可用於建立server instance的server image。

甚麼東西在伺服器裡?

思考伺服器上的各種事物以及它們的來源是必須的。

分解伺服器中事物的一種方法是將其分為軟體、配置和資料。 這些類別（如下表所示）對於瞭解設定管理工具應如何處理特定檔案或檔案集是有用的。

軟體:

應用程式、函式庫和其他代碼。 這不需要是可執行檔； 它幾乎可以是任何靜態檔案，並且不會因系統而異。 Linux 系統上的time zone data就是一個例子。而配置管理的方式是會確保每個相關伺服器上的資訊都是相同的，但 不在乎裡面有什麼。

配置(Configuration):
用於控制系統和(或)應用程式如何運作的檔案。 伺服器之間的內容可能會有所不同，具體取決於伺服器的角色、環境、instance等。 這些檔案作為基礎設施的一部分進行管理，而不是由應用程式本身管理的配置。 例如，如果應用程式具有用於管理使用者設定檔的 UI，則從基礎架構的角度來看，儲存使用者設定檔的資料檔案不會被視為配置檔； 相反，這是資料。 但是，從這個意義上來說，儲存在檔案系統上並由基礎設施管理的應用程式設定檔將被視為配置。而配置管理的方式是會在伺服器上建立檔案內容； 確保其一致。

資料:
由系統和應用程式所產生和更新的檔案。 基礎設施可能對此資料負有一些責任，例如資料的分發、備份或複製。 但基礎設施將檔案的內容視為黑盒子，是不關心它們的內容。 資料庫資料檔案和日誌檔案就是這種意義上的資料範例。而配置管理的對待的方式是它是自然發生和變化； 可能需要保存它，但不會嘗試管理裡面的東西(因為有另一種管理員需要來管理其內部)。

配置檔和資料之間的差異在於自動化工具是否自動管理檔案內的內容。 因此，儘管系統日誌對於基礎架構至關重要，但自動化配置工具仍將其視為資料。 同樣，如果應用程式將其帳號和使用者等資訊儲存在伺服器上的檔案中，則伺服器設定工具會將該檔案視為資料。

東西從哪裡來的?

可以是在建立和設定伺服器時或在改變伺服器時新增構成server instance的軟體、設定和資料。 這些元素有幾個可能的來源（如下圖 ）：

• Base OS
  OS installation image可以是實體磁碟、ISO 檔案或自己做的server image。 OS安裝過程可以選擇可選組件。
• OS package repositories
  OS安裝或post-installation configuration step可以運行一種工具，從一個或多個儲存庫下載並安裝software package。 OS廠商通常會提供包含他們支援的軟體包的儲存庫。 我們可以使用開源或商業版package的第三方儲存庫。 也可以為內部開發或策劃的套件有一個內部儲存庫。
• Language、framework與其他平台儲存庫
  除了特定於OS的套件之外，還可以安裝語言或框架的套件，例如 Java函式庫或 Ruby gems。 與OS套件一樣，可以從供應商、第三方或內部團隊管理的儲存庫中存取套件。
• Nonstandard packages
  一些供應商和內部團隊提供帶有自己的安裝程式的軟體，或者除了運行標準套件管理工具之外還涉及多個步驟。
• Separate material
  我們可以在應用程式或元件之外新增或修改檔案； 例如，新增使用者帳號或設定本機防火牆規則。

Server Configuration Code

第一代IaC工具專注於自動化伺服器配置。 該領域的一些工具包括：

• Ansible
• CFEngine
• Chef
• Puppet
• Saltstack

其中許多工具都使用依照pull configuration pattern安裝在每台伺服器上的代理程式。 它們提供了一個代理，可以將其安裝為服務，也可以透過 cron job定期執行。 其他工具設計為從中央伺服器運行並按照push pattern連接到每個託管伺服器。

我們可以使用這些工具中的大多數來實現pull或push模式。 如果我們使用像 Ansible 這樣專為push模式設計的工具，可以將其預先安裝在伺服器上並從 cron 運作。 另一方面，如果我們使用 Chef 或 Puppet 之類的工具（它提供了與pull模式一起運行的agent），那麼我們可以從中央伺服器執行命令，在每台電腦上登入並執行(用pull)。 因此，該工具不會限制我們使用哪種模式。

許多伺服器配置工具供應商提供儲存庫伺服器來託管配置帶碼。 其中的範例包括 Ansible Tower、Chef Server 和 Puppet master。 它們可能具有附加功能，例如Configuration registry、儀表板、日誌記錄或集中執行。

可以說，選擇提供all-in-one工具生態系統的供應商可以簡化基礎設施團隊的工作。 然而，如果生態系統的元素可以替換為不同的工具，那麼團隊可以選擇最適合他們需求的部分。 例如，如果我們使用與設定Registry整合的多個工具，我們可能會喜歡使用獨立的通用configuration registry，而不是與伺服器設定工具綁定的Registry。

Server Configuration Code Modules

伺服器配置代碼與任何代碼一樣，如果沒有管理好一定隨著時間的推移變得越來越混亂。 這需要紀律和良好的習慣來避免這種情況。 幸運的是，這些工具提供了將代碼組織和建置為不同單元的方法。

大多數伺服器配置工具都允許代碼組織到模組中。 例如，Ansible 有playbook，Chef 將recipes分組到cookbook中，Puppet 有包含manifests的模組。 我們可以單獨組織、版本化和發布這些模組。

角色(Roles)是一種標記一組模組以應用於伺服器並定義其用途的方法。 與其他概念不同，大多數工具供應商似乎都同意使用術語「角色」來表示此目的，而不是供應商自己編的術語。

其中許多工具還支援對其核心資源模型的擴展。 工具的語言提供伺服器資源實體的模型，例如使用者、套件和檔案。 例如，我們可以編寫一個 Chef Lightweight Resource Provider來新增 Java 應用程式資源，用於安裝和設定由開發團隊編寫的應用程式。 這些擴充類似於stack module。

設計Server Configuration Code Modules

我們應該圍繞一個單一的、有凝聚力的關注點來設計和編寫每個伺服器配置代碼模組（例如，每個cookbook或play）。 該建議遵循關注點分離的軟體設計原則。 一種常見的方法是為每個應用程式提供一個單獨的模組。

例如，可以建立一個模組來管理 Tomcat 等應用程式伺服器。 該模組中的代碼將安裝 Tomcat 軟體、運行該軟體的使用者帳號和群組，以及具有日誌和其他檔案正確權限的資料夾。 它將建立 Tomcat 配置文件，包括配置連接埠和設定。 該模組程式碼還將 Tomcat 整合到各種服務中，例如日誌聚合、監控和process management。

許多團隊發現根據用途不同地設計伺服器配置模組很有用。 例如，可以將模組分為函式庫模組和應用程式模組（對於 Chef，這將是library cookbooks與application cookbooks）。

函式庫模組管理可由應用程式模組重複使用的核心概念。 以 Tomcat 模組為例，可以編寫該模組來取得參數，因此該模組可用於配置針對不同目的而最佳化的 Tomcat instance。

應用程式模組（也稱為wrapper module）導入一個或多個函式庫模組並設定其參數以實現更具體的目的。 我們可以擁有一個安裝 Tomcat 來執行其產品目錄應用程式的 Servermaker 模組，以及另一個安裝 Tomcat 來執行其客戶管理應用程式的 Servermaker 模組。 這兩個模組都使用安裝 Tomcat 的共享函式庫。

伺服器代碼的版控和升級

與任何代碼一樣，我們應該能夠在將伺服器代碼應用到生產系統之前在環境之間測試和改進伺服器代碼。 一些團隊將所有伺服器代碼模組作為一個單元一起版本化和升級，或者將它們構建在一起，或者在將它們組合起來使用之前單獨地構建和測試它們。

如果將每個模組作為單獨的Unit進行管理，則需要處理它們之間的任何依賴關係。 許多伺服器配置工具可讓我們在descriptor中指定模組的依賴關係。 例如，在 Chef cookbook中，可以在cookbook metadata的 dependent field中列出依賴項。 伺服器配置工具使用此規範下載依賴模模組並將其套用到Server instance。 Server configuration modules的依賴關係管理的工作方式與軟體套件管理系統（例如 RPM 和 Python pip 套件）相同。

我們還需要儲存和管理不同版本的server configuration code。 通常，會有一個應用於生產環境的代版本，而其他版本正在開發和測試。

Server Roles

如前所述，Server Roles是一種定義一組套用於伺服器的configuration module的方法。 Roles還可以設定一些預設參數。 例如，可以建立Application server role:

role: application-server
  server_modules:
    - tomcat
    - monitoring_agent
    - logging_agent
    - network_hardening
  parameters:
    - inbound_port: 8443

將這個Role指派給伺服器會套用 Tomcat、監視和日誌記錄代理程式以及網路強化的設定。 它還為inbound port設定一個參數， network_hardening 模組用來在本地防火牆中open port，同時鎖定其他所有port的參數。

角色(roles)沒有管好可能會變得很亂(一個企業也是如此)，因此應該謹慎並一致性地使用它們。 我們可能更喜歡建立細緻度高的角色，將它們組合起來組成特定的伺服器。 可以向特定伺服器指派多個角色，例如Application server、Monitored Server 和 PublicFacing Server。 每個角色都包含少量用於特定用途的伺服器模組。

或者，可能擁有更高等級的角色，其中包括更多模組。 每台伺服器可能只有一個角色，這個角色可能非常具體； 例如，ERP Server 或 Jira Server。

常見的方法是使用role inheritance。 定義一個基本角色，其中包括所有伺服器通用的軟體和配置。 該角色可能具有網路強化、管理使用者帳戶以及用於監視和日誌記錄的代理程式。 然後加入更具體的角色，例如應用程式伺服器或容器主機，包括基本角色，然後添加一些額外的伺服器配置模組和參數：

role: base-role
  server_modules:
    - monitoring_agent
    - logging_agent
    - network_hardening

role: application-server
  include_roles:
    - base_role
  server_modules:
    - tomcat
  parameters:
    - inbound_port: 8443

role: shopping-service-server
  include_roles:
    - application-server
  server_modules:
    - shopping-service-application

此代碼範例定義了層次結構中的三個角色。 shopping-service-server角色繼承了應用程式伺服器角色的所有內容，並加入了一個模組來安裝要部署的特定應用程式。 application-server角色繼承自base-role，增加了Tomcat伺服器和network port configuration。 Base role定義了一組核心的通用configuration modules。

測試伺服器代碼

我們在Part 8解釋了自動化測試和 CD 理論如何應用於基礎設施，Part 9描述了使用Infrs stack來實現這一點的方法。 這兩章中的許多概念都適用於測試伺服器代碼。

漸進式地測試伺服器代碼

代碼設計和測試之間存在著一種自我強化的動態。 為結構清晰的codebase編寫和維護測試變得更加容易。 編寫測試並讓它們全部通過，迫使我們保持乾淨的結構。 將每個變更推送到運行測試的流水線中可以幫助團隊保持持續重構(refactoring)的紀律，以最大限度地減少技術債和設計債。

前面描述的伺服器角色結構由伺服器配置模組組成，這些模組本身可以組織為函式庫模組和應用程式模組，非常適合漸進式測試策略。 一系列的流水現階段可以在不斷增加的整合階段中測試其中的每一個階段，如下圖所示。

每當有人對每個代碼模組提交變更時，都會有一個單獨的階段測試該模組。 伺服器角色也有測試階段。 每當角色使用的模組之一發生變更並通過自己的階段時，伺服器角色階段就會執行測試。 當有人提交角色代碼(role code)的變更（例如新增或刪除模組或更改參數）時，角色測試階段也會運作。

使用伺服器代碼測試甚麼

決定用伺服器代碼測試什麼是很棘手的。 這又回到了測試宣告式代碼是否有任何價值的問題。 伺服器代碼模組，尤其是在設計良好的codebase中，往往較小、簡單且集中。 例如，安裝 Java JVM 的模組可能是一條帶有幾個參數的語法：

package:
  name: java-${JAVA_DISTRIBUTION}
  version: ${JAVA_VERSION}

在實踐中，即使是看似簡單的套件安裝模組也可能有比這更多的代碼，自訂＂file paths、configuration files＂，也許還加上使用者帳號。 但通常沒有太多可測試的東西，只是簡單地重述代碼本身。 測試應關注常見問題、可變結果和代碼組合。

考慮常見問題、實踐中容易出錯的事情以及如何進行健全性檢查。 對於簡單的軟體包安裝，可能需要檢查該命令在預設使用者路徑中是否可用。 因此，測試將呼叫該命令，並確保它已執行：

given command 'java -version' {
its(exit_status) { should_be 0 }
}

如果根據傳遞給它的參數，套件可能會產生完全不同的結果，那麼應該編寫測試以確保它在不同情況下代碼行為正確。 對於 JVM 安裝包，可以使用 Java 發行版的不同值來執行測試，例如確保無論選擇哪個發行版，java 指令都可用。

在實踐中，整合的元素越多，測試的價值就越高。 因此，可以為Application server role編寫和運行比該角色包含的模組更多的測試。

當這些模組相互整合和互動時尤其如此。 安裝 Tomcat 的模組不太可能與安裝監控代理程式的模組發生衝突，但安全性強化模組可能會導致問題。 在這種情況下，我們可能希望在Application server role上執行測試，以確認即使在Port被鎖定後Application server也已啟動並接受請求。

如何測試伺服器代碼

大多數自動化伺服器代碼測試都是透過在伺服器或container instance上執行命令並檢查結果來運作的。 這些測試可以斷定資源的存在和狀態，例如套件、檔案、使用者帳號和正在運行的Process。 測試也可能會考察結果； 例如，連接到網路port以證明服務是否會傳回預期結果。 用於測試伺服器條件的熱門工具包括 Inspec、Serverspec 和 Terratest。

測試完整Infra stack的策略包括離線和線上運行測試，線上測試涉及在基礎設施平台上把事物運轉起來。 通常可以使用容器或本機VM離線測試伺服器代碼。 本地作業的基礎設施開發人員可以建立具有最少OS安裝的container instance或本地VM，server configuration code，然後執行測試。

測試伺服器代碼的流水現階段也可以執行相同的操作，在agent上container instance或VM（例如，運行作業的 Jenkins node）。 或者，該階段可以在container cluster上啟動獨立的container instance。 當流水線編排器本身容器化時，這種方法效果很好。

我們可以按照堆疊指南來編排伺服器代碼設定。 這包括在執行測試和報告結果之前編寫設定測試先決條件的腳本，例如container instance。 我們應該執行與從流水線服務進行測試相同的腳本來進行本機測試，以便結果保持一致。

建立新的Server Instance

前面描述的基本伺服器生命週期從建立新的Server Instance開始。 更長的生命週期包括建立和更新server image的步驟，我們可以從中建立server instance，這個我們會在Part 13中提到。 目前，我們的生命週期從建立instance開始，如下圖所示。

完整的伺服器建立流程包括配置server instance，使其完全可供使用。 建立和配置server instance涉及的一些活動包括：

• 分配基礎設施資源以實例化server instance。 為此，需要從Pool中選擇一台實體伺服器，或選擇一台host server將其作為VM運行。 對於VM，主機上的管理程式軟體分配記憶體和其他資源。 該程序還可以為server instance的磁碟區分配儲存。
• 安裝OS和初始軟體。 OS可以複製到disk volume上，就像從 AMI 等server image啟動時一樣。 或者，New instance可以執行安裝過程，選擇檔案並將其複製到new instance，可能使用可編寫腳本的安裝程式。 腳本化OS安裝程式的範例包括 Red Hat Kickstart、Solaris JumpStart、Debian Preseed 和 Windowsinstallation answer file。
• 附加的configuration套用在server instance。 在此步驟中，該程序將按照Part 12中「如何套用伺服器設定代碼」中所述的模式來執行伺服器設定工具。
• 配置並附加網路資源和Policy。 此過程可以包括將伺服器指派給network address block、建立路由以及新增防火牆規則。
• 使用服務註冊Server instance。 例如，將新伺服器新增至監控系統。

這些並不是相互排斥的 — 伺服器建立過程可能會使用一種或多種方法來運行這些不同的活動。 可以使用多種機制來觸發server instance的建立。 讓我們逐一回顧這些機制。

手動建立新的server instance

基礎架構平台提供建立新伺服器的工具，通常是 Web UI、命令列工具，有時還包括 GUI 應用程式。 每次建立新伺服器時，都可以選擇所需的選項，包括source image、要指派的資源和網路資訊：

$ jasoncloud server new \
  source-image=stock-linux-4.56 \
  memory=4GB \
  vnet=appservers

雖然使用 UI 和命令列工具來試驗平台很有用，但這並不是創建業務中所需的伺服器的好方法。 前面討論的建立和配置stack的相同原則也適用於伺服器。 手動設定選項容易產生錯誤，並導致伺服器配置不一致、系統不可預測以及維護作業過多。

使用腳本來建立伺服器

我們可以編寫具有一致地建立伺服器的腳本。 此腳本包裝命令列工具或使用基礎設施平台的 API 建立server instance，在腳本代碼或configuration中設定組態選項。 建立伺服器的腳本是可重複使用的、一致的且透明的。 這與Stack的腳本參數模式具有相同的概念。

jasoncloud server new \
  source-image=stock-linux-4.56 \
  memory=4GB \
  vnet=appservers

此腳本與前面的命令列範例相同。 但因為它是在腳本之中，所以團隊中的其他人可以看到其他人如何建立伺服器。 他們可以建立更多伺服器，並確信它們的行為與團隊規範創建的伺服器相同。

在 Terraform 和其他stack management tools出現之前，大多數團隊都編寫了用於建立伺服器的腳本。 我們通常使用設定檔來配置腳本，就像stack configuration模式一樣。 但通常都會花太多時間改進和修復這些腳本。

使用Stack Management Tool來建立伺服器

使用Part 5中討論的stack management tools，我們可以在其他基礎設施資源的背景脈絡中定義伺服器，如下範例所示。 該工具使用平台 API 來建立或更new server instance。

server:
  source_image: stock-linux-4.56
  memory: 4GB
  vnet: ${APPSERVER_VNET}

使用stack management tools建立伺服器如此方便有幾個原因。 一是該工具負責處理我們必須在自己的腳本中實現的邏輯，例如錯誤檢查。 Stack的另一個優點是它可以處理與其他基礎設施元素的整合。 例如，將伺服器附加到Stack中定義的網路結構和儲存。 上面範例中的代碼使用變數 ${APPSERVER_VNET} 設定 vnet 參數，該變數可能會引用在stack code另一部分中定義的網路結構。

配置平台來自動建立伺服器

大多數基礎設施平台可以在特定情況下自動建立新的server instance。 兩個常見的情況是AutoScaling（加入伺服器來處理負載增加）和Auto-recovery（在server instance發生故障時更換成新的）。 通常可以使用stack code來定義它，如以下範例所示。

server_cluster:
  server_instance:
    source_image: stock-linux-4.56
    memory: 4GB
    vnet: ${APPSERVER_VNET}
  scaling_rules:
    min_instances: 3
    max_instances: 9
    scaling_metric: cpu_utilization
    scaling_value_target: 50%
  health_check:
    type: http
    port: 8443
    path: /health
    expected_code: 200
    wait: 90s

此範例告訴平台保持至少 3個、最多 9個server instance運作。 此平台根據需求新增或刪除instance，以將各個instance的 CPU 使用率保持在接近 50% 的水平。

該定義還包括健康檢查。 此檢查會在連接埠 8443 上向 /health 發出 HTTP request，如果request回船 200 HTTP 回應碼，則認為伺服器運作狀況良好。 如果伺服器在 90 秒後沒有傳回預期的回應碼，平台就會認為伺服器已失敗，因此會刪除它並建立一個new instance。

使用Networked Provisioning Tool建立伺服器

在Part 3中，我們提到了bare-metal cloud，它動態配置硬體伺服器。 執行此操作的過程通常包括以下步驟：

1. 選擇一個未使用的實體伺服器並觸發其以伺服器韌體支援的「network install」模式啟動（例如，PXE boot）。
2. 網路安裝程式從簡單的引導OS Image引導伺服器來啟動OS安裝。
3. 下載OS installation image並將其複製到主硬碟。
4. 重新啟動伺服器以在設定模式下啟動OS，執行無人看管的腳本化OS安裝程式。

有許多工具可以管理此過程，包括：

• Crowbar
• Cobbler
• FAI, or Fully Automatic Installation
• Foreman
• MAAS
• Rebar
• Tinkerbell

我們可以boot準備好的server image，而不是啟動OS installation image。 這樣做可以為實行preparing servers的其他一些方法創造機會，如下一節所述。

PS:
FaaS serverless code可以在配置新伺服器方面發揮作用。 我們的平台可以在流程中的不同時間點（建立new instance事前，中與後）運行代碼。 範例包括將安全性原則指派給新伺服器、將其註冊到監視服務或執行伺服器設定工具。

Prebuilding Servers

如前所述，新伺服器有多個內容來源，包括OS安裝、從儲存庫下載的軟體包以及複製到伺服器的自訂設定檔和應用程式檔案。

雖然我們可以在建立伺服器時組裝所有這些內容，但還有多種方法可以提前準備伺服器內容。 這些方法可以優化建立伺服器的過程，使其更快、更簡單，並且更容易建立多個具一致性的伺服器。 以下是執行此操作的幾種方法。 此後的部分解釋了在配置過程之前、中、後套用配置的選項。

Hot-Cloning a Server

大多數基礎設施平台都可以容易複製正在運行的伺服器。 以這種方式hot-cloning伺服器既快速又簡單，並且提供在clone時保持一致的伺服器。

當想要在不干擾伺服器運行的情況下探索伺服器或對其進行故障排除時，clone正在運行的伺服器會非常有用。 但它也存在一些風險。 一是為實驗而製作的生產伺服器副本可能會影響生產環境。 例如，如果複製的應用程式伺服器配置為使用生產資料庫，很可能會意外污染或損壞生產資料。

在生產環境中運行的clone伺服器通常包含來自原始伺服器的歷史數據，例如日誌檔案資訊。 這種資料污染會使故障排除變得混亂。 會導致人們花時間思考錯誤訊息，結果發現這些錯誤訊息並不是來自他們正在除錯的伺服器。

而且clone伺服器並不能真正複製。 在不同時間點從同一parent server複製的兩個伺服器會有所不同，並且無法返回並建立第三個伺服器並完全確定它是否以及如何與其他任何伺服器不同。 clone伺服器是configuration drift的根源。

使用Server Snapshot

我們可以snapshot正在運行的伺服器的快照並用來建立伺服器，而不是透過直接複製正在運行的伺服器來建立新伺服器。 同樣，大多數基礎設施平台都可以輕鬆地向快照伺服器提供命令和 API 呼叫，從而建立static image。 這樣，可以根據需求建立任意數量的伺服器，並確信每台伺服器都與starting image相同。

然而，從運行中伺服器的快照建立伺服器還有許多hot-cloning的其他缺點。 快照可能會受到來自原始伺服器的日誌、配置和其他資料的污染。 從頭開始建立乾淨的server image會更有效。

建立一個乾淨的Server Image

Server Image是從乾淨、已知的來源建立的快照，以便可以建立多個具一致性Server instance。 可以使用與運作中伺服器快照相同的基礎架構平台功能來執行此操作，但原始server instance永遠不會用作整個系統的一部分。 這樣做可以確保每台新伺服器都是乾淨的。 建構Server image的典型過程是：

1. 從已知來源建立新的server instance，例如OS供應商的installation image，或基礎架構平台為此目的提供的image。
2. 應用server configuration code或在伺服器上執行其他腳本。 這些可能會在所有伺服器上安裝想要的標準套件和agent，出於安全目的強化配置，並套用所有最新修補程式。
3. 對伺服器進行快照，建立一個可用作建立多個server instance的source image。 執行此操作可能涉及將快照標記為用於建立新伺服器的image的步驟。 它還可能涉及標記和版控，以幫助管理多個server image的儲存庫。

我們有時將server image稱為golden image。 儘管有些團隊可能會遵標準步驟清單來手動建立這些image，但我們會立即看到自動化此流程、將server image作為代碼管理的效益。 建置和交付server image將是Part 13的主題。

配置一個新的Server Instance

本文描述了伺服器的元素是什麼、它們來自哪裡、建立new server instance的方法以及預先建置server image的價值。 伺服器建立和配置過程的最後一部分是將automated server configuration code套用至新伺服器。在此過程中有幾個點可以執行此操作，如下圖所示。

可以在建立Server image、從Image建立server instance以及伺服器運行時套用配置：

配置Server Image
在建置將用於建立多個server instance的server image時套用設定。 將此視為配置只做一次並能多次使用。 這通常稱為baking a server image。

配置新的server instance
可以在建立new server instance時套用配置。 將此視為能多次性配置。 這有時稱為“frying a server instance”。

配置正在運行的server instance
將設定套用至已在運作的伺服器。 這樣做的一個常見原因是進行變更，例如應用安全性修補程式。 另一個原因是回復在自動化配置之外所做的任何變更以強制一致性。 一些團隊也應用配置來改造現有伺服器； 例如，將Web server變成Application server。

最後一個，配置正在運行的Server instance，通常用於更改伺服器，這是Part 12的主題。前兩個是創建新伺服器時套用Configuration的選項，因此完全屬於本文的範圍。 主要問題是確定為新伺服器套用程式配置的正確時間 — 將其套用(frying)到每個new server instance中，還是將其放在到server image中？

Frying a Server Instance

如前所述，frying server涉及在建立new server instance時應用配置。 我們可以將其發揮到極致，將每個server image保持在最低限度，並將特定內容給予於特定伺服器的所有內容建置到Live image中。 這樣做意味著新伺服器始終擁有最新的變更，包括系統修補程式、最新的軟體包版本和最新的配置選項。 Frying server是交付時間整合的一個例子。

這種方法簡化了Image管理。 Image並不多，基礎架構中使用的硬體和OS版本的每種組合可能只有一個，例如，一個用於 64 位元 Windows 2019，一個用於 32 位元和 64 位元 Ubuntu 18.x。 這些Image不需要經常更新，因為它們沒有太多變化。 無論如何，我們可以在配置每台伺服器時套用最新的補丁。

某些團隊在採用基礎設施自動化的早期就專注於Frying。 設定用於管理伺服器image的工具和流程需要花費大量精力。 我們將這項工作放在待辦事項中，以便在建立核心基礎設施管理後完成。

在其他情況下，Frying是有意義的，因為server變化很大。 例如一家託管公司讓客戶從大量客製化server中進行選擇。 該公司維護極簡的base server image，並在配置每台新伺服器的自動化方面投入更多精力。 建立每個instance時安裝和配置伺服器元素有以下潛在問題：

速度
建置伺服器時發生的活動會增加建立時間。 對於馬上要伺服器上線以處理負載峰值或從故障中恢復來說，增加的時間是一個特殊問題。

效率
配置伺服器通常涉及透過網路從儲存庫下載套件。 這可能既浪費流量又緩慢。 例如，如果需要在短時間內啟動 20 台伺服器，讓每台伺服器下載相同的修補程式和應用程式安裝程式就很浪費資源。

依賴項
配置伺服器通常取決於工件(artifact)儲存庫和其他系統。 如果其中任何一個離線或無法存取，我們將無法建立新伺服器。 在需要快速重建大量伺服器的緊急情況下，這可能會特別痛苦。 在這些情況下，網路設備或儲存庫也可能會關閉，從而需要建立一個複雜的流程圖，其中首先重新啟動或重建哪些系統以使下一組系統能夠依序啟動。

Baking Server Images

伺服器建立光譜的另一端是將幾乎所有內容配置到server image中。 建置新伺服器就會非常快速且簡單，因為只需要套用特定於instance的配置。 Baking Server Images是建置時整合的一個範例。

從Frying的缺點可以看出Baking的優點。 將 Configuration baking到server image中特別適合使用大量類似server instance的系統，以及當需要能夠頻繁、快速地建立伺服器時。

Baking server image的一項挑戰是，我們需要設定工具和自動化流程，以便輕鬆更新和推出新版本。 例如，如果針對OS或嵌入到server image中的關鍵軟體包發布了重要的安全補丁，我們希望能夠建立new image並將其快速部署到現有伺服器，同時將中斷降至最低。 Part 13介紹如何執行此操作。

Baking server image的另一個問題是速度。 即使有成熟的自動化更新image流程，建置和發布new image也可能需要很長時間（通常為 10 到 60 分鐘）。 我們可以透過將變更推送到正在運行的伺服器或透過結合Frying和baking的流程來緩解這種情況。

將Baking與Frying組合

決定何時是應用特定配置的正確時間的主要考量因素是所需的時間和更改的頻率。 應用時間較長且更改頻率較低的內容很適合baking server image。 例如，可以在server image上安裝應用程式伺服器軟體，從而更快地啟動多個server instance並在此過程中節省網路頻寬。

在這種權衡的另一面，安裝速度更快或更改更頻繁的東西最好是Frying。 內部開發的應用程式就是一個例子。 按需(On-demand)啟動新伺服器的最常見用例之一是將測試作為軟體發布過程的一部分。

高生產力的開發團隊每天可能會推出十幾個或更多應用程式的新版本，並依靠 CI 流程自動部署和測試每個版本。 對於這種工作節奏來說，為每個新應用程式建立產生new server image太慢，因此在建立測試伺服器時部署應用程式會更有效率。

團隊將baking和frying結合起來的另一種方法是盡可能多地baking server image，但Frying更新的版本。 團隊可能會以較慢的速度baking updated server image（例如，每週或每月）。 當他們需要更新通常baking到image上的內容時，例如安全性修補程式或配置改進，他們可以將其放入伺服器創建過程中，將其放在baked image之上。

當需要baking updated image時，他們會將updated溶入到image中並將其從建立instance過程中刪除。 這種方法可以讓團隊快速融入新的變更，同時減少overhead。 團隊經常將其與持續應用代碼結合使用來更新現有伺服器，而無需重建它們。

建立伺服器時套用Server configuration

大多數用於以前面討論的方式建立伺服器的工具，無論是命令列工具、平台 API call還是stack management tool，都提供了套用server configuration code的方法。 例如，stack management tool應該具有支援流行工具或在new server instance上執行命令的語法，如以下範例所示。

server:
  source_image: stock-linux-4.56
  memory: 4GB
  vnet: ${APPSERVER_VNET}
  configure:
    tool: servermaker
    code_repo: servermaker.shopspinner.jas
    server_role: appserver
    parameters:
      app_name: catalog_service
      app_version: 4.5.6

此代碼執行 Servermaker 工具，向其傳遞託管的server configuration code的伺服器主機名稱、套用於伺服器的角色 (appserver) 以及傳遞給伺服器配置代碼的一些參數（app_name 和 app_version）。

有些工具還允許我們將伺服器配置代碼直接嵌入到stack code或要執行的 shell command中。 使用它來實現server configuration logic可能很吸引人，並且對於簡單的需求，這可能沒問題。 但在大多數情況下，該代碼的大小和複雜性都會隨時間的推移而增加。 因此，最好提取代碼以保持codebase的整潔和可維護性。

結論

本文涵蓋了建立和配置新伺服器的各個面向。 伺服器上的事項類型包括軟體、配置和資料。 這些通常取自base OS installation和各個儲存庫的軟體包，包括由OS和language vendors、第三方和內部團隊管理的軟體包。 我們通常會透過組合server image中的內容並使用伺服器配置工具來套用其他套件和配置來建立伺服器。

※本文由 運用雲端服務加速企業數位轉型 授權勿任意轉載，原文《IaC Part 11 -Building Servers as Code》

這篇文章 【學長姊帶路】IaC Part 11 -Building Servers as Code 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《【2022 平面設計師轉職 UI 設計師】Sketch、Adobe XD、Figma 如何選擇適合自己的UI設計工具！》

文/TWJOIN 哲煜科技 | 台灣 | 客製化軟體應用解決方案供應者 - UIUX設計部

對於剛開始要轉職 UI 設計的新手設計師，目前UI介面設計軟體越來越多，Sketch、AdobeXD、Figma、InVision、PhotoShop、illustrator 等等…

每個設計軟體都有產品特色也都有大神手把手教學，其中又以 Sketch、Adobe XD、Figma 為主流UI設計工具。

由於公司最近剛來了一位 UI 設計師的平面新人，問了為什麼我們公司用Figma為主要 UI 設計工具，而不是其他設計軟體，藉由這個機會也整理了這篇文章單說明一下主流軟體常用功能使用心得！

Sketch：UI設計軟體先鋒

我最早使用的UI設計軟體記得最初都是看國外YouTuber Sketch Together 及Sketch相關文章學習了很多技巧(Ｇoogle 翻譯真的是太給力)…畢竟當時中文教學沒人做～😵‍💫 ，先鋒當然還有巨量 Free 資源 讓我覺得這也太佛心了吧！

UI設計軟體逐漸增加，Sketch很多功能都是因應市場需求增加(Prototype、Collaborate、Sync) 身為先鋒就慢慢的變成追隨競爭對手的腳步…但是不能不說Sketch Symbols巢狀元件庫真的很好用！

Sketch 官方特色說明

🖥︎ 作業系統：MacOS
💸 費用：「Free 30 /days 」「$9USD /month」「$99USD /year」
👀 即時溝通與協作：🍤 （弱弱Der~）
🌥 雲端空間：無上限
📂 檔案：本機上傳
🔌 Plugin：🍤🍤🍤🍤🍤🍤🍤🍤🍤 （巨量插件）
📱 Prototype：🍤（弱弱Der~）
💠 Symbols： 🍤🍤🍤🍤🍤（很推薦使用，但對於新手不友善）
🎛 Autolayout：🍤🍤🍤（普通）

對於有 MacBook 新手 UI 設計師是強烈建議可以試試 Sketch UI先鋒的 Symbols 強大的功能，我也是被海量的設計資源及Symbols 綁架了很久…

Adobe XD：整合雲端設計

在AdobeXD出來之前(2017)，擁有MacBook設計師可使用Sketch製作UI介面設計，而Windows設計師主要使用PhotoShop來製作設計。PS 製作UI介面需解決問題非常多（切圖尺寸、專案多個檔案），畢竟PS是點陣圖並非向量。

Adobe 推出 XD介面設計軟體。極簡純白色介面(個人覺得深色比較有fu~)與 AI、PS、Sketch(想讓Sketch 老粉跳槽) 的軟體相容性，Windows、MacOS支援雙平台，真的是讓想學習UI介面設計師降低了門檻（孔金ㄟ魅克普羅）。

AdobeXD 的特色功能像是 Main Component (類似Sketch Symbols 狀態切換)，厲害的 Auto-animation 、Repeat Grid、3D Transforms及快速雲端連結Share Prototype 給其他人，真的是比UI先鋒強大許多。

AdobeXD 官方特色說明

🖥︎ 作業系統：MacOS、Windows
💸 費用：「 Free 」需要登入 Adobe Creative Cloud
👀 即時溝通與協作：🍤🍤🍤（使用起來有點Lag…）
🌥 雲端空間：100GB
📂 檔案：本機上傳
🔌 Plugin：🍤🍤🍤🍤🍤（官方插件庫陸續增加中…）
📱 Prototype：🍤🍤🍤🍤🍤（越來越強大～）
💠 Components： 🍤🍤🍤🍤（對於新手非常友善，操作簡單）
🎛 Autolayout：🍤🍤🍤🍤🍤（很好用100%）

AdobeXD 開發團隊非常用心一直在優化功能，Auto-animation的推出讓設計師可以簡單設定就能達到想要效果，不須透過外掛插件 Anima 或是其他Prototype工具來製作效果。最近還更新支援了 JSON格式 及影片連結，更容易用 XD來製作展示高品質 Prototype 太厲害了～

Figma：UI設計師俘虜神器

為什麼是俘虜神器呢？Figma 可在瀏覽器中編輯共同協作專案，可忽略任何作業系統（目前也有應用程序版 MacOS、Windows），超順暢的線上協作不卡頓，Figma 除了超強線上協作功能外，還匯集了AdobeXD、Sketch喜愛的強大設計功能，並優化了自動佈局進行響應式設計Autolayout，讓設計師花更多的時間進行設計，而花更少的時間重複調整。

什麼是Figma AutoLayout ?? 為何如此強大！！

官方Plugin外掛及共享資源目前已經多到數不清而且外掛安裝下載量超級驚人可想而知，有多少設計師已經被Figma所俘虜，成為Figma用戶。

在Prototype方面Figma 獨特的 Smart animate 更是驚人啊～只要了解操作邏輯便能製作超擬真原型，在開發特效時設計師跟工程師的溝通，很多時候靠雙方通靈及蝦到爆的比手畫腳比喻找範例，才能做出設計師想要的酷炫效果。有了Figma大大減少溝通時間，如果你還不了解有多麽強大，可以跟著這位大神學習 Figma Smart animate 產品頁面製作 Igor Vensko Tutorials 。

Figma 官方特色說明

🖥︎ 作業系統：MacOS、Windows、瀏覽器
💸 費用：「Free / 3 Figma / 3 FigJam」「$12USD /month」
👀 即時溝通與協作：🍤🍤🍤🍤🍤🍤🍤🍤🍤🍤🍤（順暢無比）
🌥 雲端空間：無上限
📂 檔案：雲端檔案即時存擋（有網路不怕當機）
🔌 Plugin：🍤🍤🍤🍤🍤🍤🍤🍤（…）
📱 Prototype：🍤🍤🍤🍤🍤🍤🍤🍤（…）
💠 Components： 🍤🍤🍤🍤（對於新手友善，操作簡單）
🎛 Autolayout：🍤🍤🍤🍤🍤🍤🍤（爆幹方便好用500%）

Figma還有很多好用的功能，趕快被俘虜吧～沒什麼好說的哈哈哈…

小結

公司因為UI設計師增加，以前用 Sketch 檔案互傳合併檔案造成很多時間及格式問題，所以決定轉換成有強大協作能力 Figma 作為首要設計工具。全公司 UI 設計師都被 Figma 俘虜。

目前已經熟悉了 Figma 協作及更多功能後，回去修改 Sketch 檔案時更能了解 Sketch 功能真的沒有這麼人性化的操作。你可能會問轉換軟體會不會有陣痛期，「答案：沒有！」因為介面基本上都一模一樣，但有些相異的地小地方需要熟悉一下。

很多人會有軟體迷失：「誰誰誰用什麼軟體做很厲害耶！」啊～我用OOXX 怎麼做這麼爛是不是要換軟體，這跟軟體沒有毛關係，重點在於你自己是否熟練軟體特性，每個軟體都有優缺點，只要掌握軟體特性符合自己的操作需求就可以，好的設計師不會因為用什麼工具而限制設計能力。

感謝閱讀到最後的你！

希望你已經知道要選擇什麼UI設計工具，那你應該要幫我拍手，更應該馬上去做！Just do it ! GL HF！

也歡迎按讚並關注 哲煜科技的粉絲專頁 喔 ! 感謝閱讀到最後的你。

※本文由 TWJOIN 哲煜科技 | 台灣 | 客製化軟體應用解決方案供應者 - UIUX設計部 授權轉載, 原文:《【2022 平面設計師轉職 UI 設計師】Sketch、Adobe XD、Figma 如何選擇適合自己的UI設計工具！》

這篇文章 【學長姊帶路】如何選擇適合自己的UI設計工具！ 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《[鼠年全馬鐵人挑戰]Week10-使用Azure DevOps Service 實現完整應用程式開發到自動化部署過程(2)》

文/Nina Weng

創建 Azure Container Registry (ACR)

1. 打以下指令利用Azure CLI 建立，或是直接在Azure網頁上建立。

az acr create -g MyAKS -n NinaK8S sku Basic admin-enabled true

-g 資源群組； -n 容器登錄名稱； skuACR 有多個服務層級，叫做SKU。不同的層級收費不一樣，有Basic, Classic, Premium, Standard 四種可選。admin-enabled 啟用管理員帳戶，讓我們之後用密碼來做upload或push等功能。

建立成功後可以看到在 MyAKS 的資源群組裡面多了一個剛剛建立的 ACR NinaK8S 。

點進去後可以看到有一個登入伺服器(Login Server)，注意這個值是唯一的，不可和別人重複。

2. 從 AKS 對 ACR 進行驗證

az aks update -n MyAKS -g MyAKS attach-acr NinaK8S

3. 創建一個專案

3.1 開啟 Visual Studio

3.2 建立一個 ASP.NET Core Web Application

(此篇文章以 ASP.NET Core 3.1 為範例。)

3.3 輸入專案名稱並選擇存放專案的位置

3.4 取消啟用Docker支援的勾勾

此系列文章將會介紹如何把一個ASP.NET Core 的應用程式直接加入Docker支援，所以這邊暫時取消啟用Docker支援的勾勾。

3.5 執行專案

因為我們選了MVC的範本，所以範本已經內建好一些基本的檔案程式了，可以直接Run起來，會看到以下畫面。

可以看到目前是執行在我電腦本地端57544的Port

3.6 修改首頁

我們稍微修改一下首頁，做一下區隔。

開啟Views/Home/index.cshtml，將首頁的h1標籤內容改 Welcome Nina，然後存檔。

可以看到首頁變以下畫面。

接下來介紹怎麼把專案放到Container裡面。

3.7 對專案按滑鼠右鍵>加入>Docker支援

接著可以依情況選目標的作業系統是哪一個，此篇文章這邊選Linux。

這邊可以看到 Visual Studio 幫你創了一個 Dockerfile，而從輸出視窗可以看到 Visual Studio 正在默默的在背景建立 image 中。

在命令提示字元輸入 docker images 可以看到已經成功建立image了。

3.8 Docker 執行專案

這邊可以看到Port變為32768，不是剛剛的57544了。也就是現在已經是run在docker上囉！

後面的內容下集待續，如果喜歡這篇文章，麻煩幫我鼓掌一下哦，謝謝🙇‍♀️

※本文由 Nina Weng 授權勿任意轉載，原文《[鼠年全馬鐵人挑戰]Week10-使用Azure DevOps Service 實現完整應用程式開發到自動化部署過程(2)》

這篇文章 【學長姊帶路】使用Azure DevOps Service 實現完整應用程式開發到自動化部署過程 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。