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

升遷與報酬的失落感

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

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

無法得到應有回報的掙扎

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

多元職涯發展與轉型

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

重新調整生活重心

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

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

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

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

原標《在 2024 年對找第一個數據工作的學習指南》

文/AdamChang

回首過去幾年的工作時間，對數據的工作有了更深的理解，在 2024 的這個時刻，跟前幾年的數據工作已經很不一樣。數據分析的工作開始逐漸細化，在整個數據分析的完整流程中，定義了更明確的分工與角色。

而角色的分化，對於想要進入這個領域的人而言，在選擇上更加多元也更加複雜。儘管如此，市場上仍然是有一些共通的職務需求。

在這邊文章中，會從我自己的工作經驗上，跟大家分享，如果你想要進入這個職務，需要累積的共同需求，一共七個項目，希望能有助於想要進入這個職務的朋友。

一、累積統計知識

統計分析是數據分析的基礎，不管到任何產業上，只要是從事數據分析行業，基本的統計分析知識都是必須的。

學習如何分析趨勢的統計方法、學習做實驗的方法、學習分析原因的方法、學習預測的方法…等，諸如此類基於數據去了解真實世界的方式，以及透過數據去產生決策的方式，這些都是做數據分析的必要基礎。

二、學習好 SQL

SQL 算是數據分析的基本工具之一，做數據分析的第一步驟就是：我們要先取得數據。

SQL 就是取得數據之中最基本的工具，數據絕大多數都會被存取在資料庫中，雖然現在有更多元的資料型態，也有不同的取用數據的方式，但 SQL 絕對是在其中比重高的需求之一。

如果想從事數據分析，SQL 就是一定要會的技能。

三、學習 Python

拿到了數據後，就要來實際處理和分析數據，而 Python 就是目前主流在處理數據和分析數據的主要工具之一。

SQL 雖然可以取用數據，也可以處理數據，但並非唯一的處理工具，通常在實際的工作中，會和 Python 相輔相成。

學習 Python 會是想加入數據分析產業時，也需要累積的技能之一。

四、學習故事力

故事力，又稱 Storytelling。在每一個數據分析專案裡面，都需要跟合作單位、利害關係人、客戶、或是老闆等等，說明我們的分析洞見，以及說明『為什麼我們要做這個分析』。成功的提案和洞見，故事力在其中都是不可或缺的角色。

學習如何透過數據說商業故事，是成為數據分析人員的重要技能。

五、針對產業做研究

產業研究在 2024 年這個時間點，逐漸成為數據分析人員的重要技能之一。根據我自己工作上的觀察，現在有越來越多的企業，在招募數據分析人員時，都希望他們能夠透過分析，幫企業帶來新的商業洞見。

如果對數據分析工作有興趣，我非常建議大家可以針對自己有興趣的產業做研究，這份研究除了可以加深對產業的理解，同時也可以成為自己作品集的一部分，是一件非常划算的事情。

六、學習資訊系統知識

數據分析是一個跟資訊科技非常緊密結合的行業，在早期做分析時，很多時候就是從資料庫裡面撈取數據，並跑統計分析結果而已。

現在隨著資訊科技的進步，數據分析人員需要接觸的資訊工具越來越多元，比如要會雲端、會大數據處理、會機器學習、會深度學習、會資料庫的管理、會部署模型服務等等，越來越需要多元化的資訊科技服務。

學習基礎的軟體系統知識，雖然面試時不一定會考，但是會是在工作上非常加分的技能。

七、嘗試透過數據，解決真實世界的問題

有一個常見的討論是，要面試數據分析工作，需要有一個自己的作品集。

這個概念大方向來說絕對是加分的，但最好是『有意義的』作品，而不是為了做作品集而做的作品。

有意義的作品，最好是來自於解決一個真實世界的問題。比如說，我想要尋找網站上最低價的商品，所以我做了一個爬蟲比價的分析。或者說，想了解哪一個國家具有發展潛力，所以就做了國際經濟的分析。又或者是因為想找更好的工作，大量蒐集和分析求職網站的職缺，找出產業的需求是什麼。

解決真實世界的問題，會讓你的分析更有價值，也更能讓其他人感同深受，認同你的分析結果。

總結

以上這七點，是我這幾年從事數據分析工作下來，認為數據工作者可以參考的學習方向，分享給大家參考。如果你對數據分析的工作有興趣，

可以往這些方向做學習和累積。

※本文由 AdamChang 授權勿任意轉載，原文《在 2024 年對找第一個數據工作的學習指南》

這篇文章 【學長姐帶路】數據分析師必備七大技能 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

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

文／DCARD 網友

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

工作相關 💼 ：

工作內容📓：

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

工作環境🏢：

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

工作氣氛🙂：

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

個人心得 💬：

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

總結 😃：

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

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

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

原標《國泰人壽 Product Design 實習：官網預約顧問功能優化》

文/Millie Qiu

今年年初收到國泰 CAP 實習錄取通知，那份既雀躍又期待的感受至今仍然很清晰，我加入國泰人壽數位發展部擔任產品設計實習生，這半年間也累積了不少心得。

國泰敏捷實習計畫 (CAP) 是針對數位敏捷科技人才的學期間實習計畫，以專案導向為主，必須在 2–6 月的學期間，與 PM 一同合作完成專案目標。

這篇文章主要是記錄我的專案成果及思考脈絡，同時也會摻雜學習的心路歷程及筆記。因為接觸 UI/UX 的時間並不算長，會以初學者的視角來拆解專案流程，歡迎有興趣的各位繼續看下去！

▍專案背景

國泰人壽為台灣保險業之第一家上市公司，客戶數超過 800 萬人，在台灣幾乎每三人就有一人是國泰人壽的保戶。

在國泰人壽官網的商品頁面中，提供三種不同的諮詢方式，若客戶在使用過程中遇到任何疑問都能輕鬆解決；其中「選擇業務顧問」的簡易預約功能，更能讓客戶快速預約平台推薦的業務顧問完成投保。

三種諮詢方式分別為：預約業務顧問、諮詢商品客服、Line給我的業務員

然而我們發現，對保險商品有興趣而點進簡易預約流程的人數，跟最後實際完成預約的人數有明顯落差。

希望透過此次專案提出解決此問題的方案，降低簡易預約流程之間的放棄率，藉此促進更多筆預約數，進而提升保險商品的促約率。

設計流程

▍01 發現問題：數據分析

要進行優化，首先就必須知道問題到底出在哪，我希望能透過量化的數據找到一個強烈的動機，讓這份報告在結案時看起來不僅完整，更能真正為公司帶來效益。

因此在專案前期，我著手開始蒐集公司 Google Analytics 及 SAS 後台資料，以了解在整個簡易預約的流程中，到底是哪個環節出了問題、哪個步驟的用戶跳出率最高。

礙於我不是數據分析實習生，沒有瀏覽公司後台資料庫的權限，當所有實習生都為各自的專案忙得焦頭爛額的時候，我還是很主動（厚臉皮？）地去拜託數據 Team 的實習生，請他幫我撈出頁面上各個按鈕的點擊次數。（擁有一位熱心助人的神隊友是多麼可靠的一件事😂）

另外，由於 Google Analytics 推出新版的 GA4，能夠把網頁上的 Web 資料和追蹤 APP 取得的資料放在一起，光是搞清楚名稱跟網域的定義就花了我不少時間；我利用 GA4 新推出的「探索功能」來自訂報表，一邊查詢網路上的教學、一邊看公司的同事們的設定參數，自己摸索出了一套新規則，讓我能夠用「漏斗探索報表」看出一些數據端倪。如下圖：

「漏斗探索」可用於分析使用者在網站的瀏覽過程。報表概念與「行銷漏斗」類似，是將使用者旅程拆解成不同階段、步驟，觀察使用者從接觸到行動（例如購買），各個步驟「完成」或「放棄」的情況。

簡易預約完整流程與問題（已移除機敏/實際數據）

▍02 了解問題：使用者研究

感謝被我抽空抓出來做用戶研究的朋友們🥲

手邊已經有了數據，知道問題點出在哪，下一步我希望可以直面使用者，透過易用性測試找出流程中的痛點是什麼。

我預計進行為期一週的測試，總共邀請 6 位受測者來實際操作簡易預約流程，藉此了解用戶操作網站時的想法及需求。

執行專案遇到的困難❓

BUT！九把刀曾經說過人生最厲害就是這個 BUT，可以改變很多事情，無論是好的方面或是不好的方面......

我的 Mentor 說：「客戶的資料都會保密哦！實習生沒辦法查看客戶端資料啦。」

聽起來非常合理，我當然也能接受這件事實，畢竟要是連我一個實習生都能直接聯絡到客戶，那該有多糟糕啊。

不過，沒辦法邀請真實客戶進行深度訪談，這件事確實令我有點焦慮。

所幸 Mentor 告訴我即便無法直接面對客戶，也可以先從身邊的親朋好友下手，邀請一些平時有在關注保險議題的朋友當受訪者。若是將訪綱及任務列得夠清晰明確，同樣也能從訪談中獲得有用的回饋。

她還補充，就連他們自己在做優化專案時也很難聯繫到客戶、甚至邀請客戶接受訪談，有時候光是募集受訪者就會先花上許多時間。我想這或許跟產業類別有關，金融保險業必須「注重隱私與個資」，這點是無庸置疑的。

▲Photo by UX Indonesia on Unsplash

我以前並沒有實際執行易用性測試的經驗。確定要找身邊的親友當受測者後，我上網作了許多功課，包含業界前輩們主持訪談的方法及心得、如何設計操作任務......等，過程中也與 Mentor 來回討論、修改訪綱好幾次，總算讓我拿捏到該怎麼把「問題問得精準」。

在設計訪綱前，要先設立好訪談目的及目標，釐清自己究竟想從這次的訪談中獲得什麼資訊、得到這些資訊對後續的分析有什麼幫助。

也可以思考「為什麼要問這個問題？」、「我想從這個問題知道什麼？」，讓所有的問題都依照原本設定的「目標」進行延伸，同時，也要避免問出一些引導式問題。

由於這是獨立的專案，訪談時需要的角色，包含主持人、觀察員、記錄員，全都由我一手包辦！要同時參考訪綱上列的題目、根據受測者的回答給予反應、思考下一題該問什麼、一邊打字做紀錄，我覺得在那六場訪談裡，我把大腦的多工功能發揮到淋漓盡致。

我承認這不是一個良好的訪談進行方式。思考時間太短，容易忽略掉一些小細節；甚至因為要打字紀錄，我也無法同步觀察受測者的表情變化。好在當時我有開啟螢幕錄影的功能，算是有稍微彌補這部分的缺失。

這次採用「放聲思考」訪談法，受測者需要操作指定任務同時將心中的想法講出，講出他們看到了什麼、想到了什麼、感覺如何，鼓勵受測者盡量講出心中的想法。

經過一番統整及分析，得到以下的操作結果：

💡 此階段的 Key Insight：

「幾乎所有受測者都對『自選顧問』的功能感到驚喜，且相當滿意這個功能。」

比起「只填寫表單就送出預約，不曉得來聯繫的顧問是誰」，受測者更喜歡能夠自己決定要預約哪幾位顧問，選擇的彈性度越高，越能對顧問產生的親切感及信任感。

▍03 定義問題：測試操作結果

綜合受測者操作時的描述，不斷詢問「為什麼」來挖掘受測者說出這句話時，背後的問題究竟為何。

其中一個問題是「進入點的按鈕文案引導不夠清晰」，且沒辦法看出後續有提供自選顧問的功能。若多數的使用者都相當滿意這個服務，是不是應該在前面就更凸顯這項優勢，來做出與競業的區別？

因此，我將我將這次專案的目標設定為：「如何能更強調自選顧問功能，以提升用戶的操作體驗」，並收斂出三項優化方向。

▍04 解決問題：流程規劃

在整體預約流程的部分，我將「選擇顧問」移至第一步驟，希望搭配進入點按鈕的文案調整，將使用者對服務的滿意度在這個階段提升到最高，後續需要提供個資填寫預約資料時，就不會感到過於煩躁。

另外，將「填寫預約資料」與「簡訊驗證」整合至同一頁面，減少頁面的跳轉，以簡化簡易預約流程的步驟數。

「填 寫資料」與「自選顧問」的步驟對調，是本次專案最大的改動。

▍04 解決問題：設計稿

📌 此次介面皆按照國泰人壽官網 StyleGuide 設計，以維持官網整體設計風格的一致性，便於後續維護及開發。

Step 1：選擇預約顧問

Step 1 : 選擇預約顧問 Before | After

過去用戶必須在第一步驟先填寫表單，表單裡的其中一個問項是「所在地區」，後續系統將根據用戶填寫的所在地區篩選條件相符的顧問。

由於做了步驟順序變動，我在頁面最上方新增一個選擇所在地區的「下拉式選單」，儘管將自選顧問移到第一步驟，用戶還是可以篩選相同地區的顧問。

另一方面，當初在進行易用性測試時，曾有幾名受測者發出這樣的疑惑：「咦？我不能單獨更新其中一位顧問嗎？」、「一定要同時更新所有顧問嗎？這樣如果我只對其中一個人不滿意怎麼辦？」。我點頭如搗蒜，覺得這是一個很好的建議，在專案裡肯定要多加這個新功能！

殊不知後來我發現，網站裡早就有提供這個功能了。

— — 那為什麼受測者當初會找不到？

原來這個「單獨更新」的功能被藏在顧問卡片右上角的叉叉 icon 裡，對使用者來說實在太不直覺、不易聯想。

因此我在這邊做了 icon 樣式調整，把叉叉 icon 直接換成重新整理的圖樣，如此一來能使操作提示更直覺，使用者也不會在這個功能上迷路了。

Step 1.1：【查看簡歷】彈窗

Step 1.1 : 查看簡歷彈窗 Before | After

「怎麼每一個人的 Hashtag 都是『服務態度佳』……」點擊查看簡歷後展開的彈窗，會發現 Hashtag 中所有顧問呈現的資訊都是服務態度佳，使得這個區塊沒有被妥善利用，亦無法呈現鑑別度。

我在這邊增加 Hashtag 的數量，除了顧問的個人特質，也可以放上業績、專業證照等資訊，讓用戶可以快速了解顧問的特質與經歷，提供更多選擇顧問的參考依據。

Step 2：填寫預約資料

簡易預約 (左) | 專站預約 (右)

國泰人壽的線上預約服務分成兩種，除了此次提到的簡易預約，還有另外提供專站預約。

簡易預約主打讓用戶瀏覽完感興趣、滿意的商品後，能快速進入到預約頁面，提供一個即時、便利又好操作的預約服務，瞄準特定的某種商品組合諮詢。

專站預約則會詳細羅列出所有顧問名單，也有更詳細的資訊（包含專業領域雷達圖、自傳等），用戶能依地區、性別、年資等多樣條件進行篩選。

Step 2 : 填寫預約資料 Before | After

在這步驟參考國泰人壽專站預約的呈現方式，將表單改成兩欄式排版。除了使問題看起來較不冗長，主要也希望國泰官網品牌的視覺風格能夠盡量達到一致。

另外，聯繫時段的選項拆成「先選平日或假日，再選方便聯繫的時段」，提供用戶較彈性的時段選擇；在填寫預約資料頁面下方，增加前一步驟已選的三位顧問頭像，協助用戶做即時 Recap。

點擊上圖「發送簡訊驗證碼」，展開輸入簡訊驗證碼的區塊

Step 3：預約完成

Step 3 : 預約完成 Before | After

在預約完成頁，將重要的預約資料以卡片方式呈現，如此一來不只能告知用戶預約申請已確實送出，更能提供即時的資訊做確認，也方便截圖保存。

這點在後續報告給曾接受訪談的朋友後，得到對方的認可，覺得這個功能很貼心也很實用。（感謝 inline 訂位系統給我的靈感）

▍反思與學習

這是我自學 UI/UX 以來首次獨立完成一個完整的產品流程優化專案，也認知到 UX 領域真的是一個大坑，光是前期的研究方法就可以拆分成好幾種。

一開始在做功課時，網路上的資料密密麻麻、看得我眼花撩亂......但這也讓我更確信自己對於這個領域的熱忱與熱愛，一想到還有許多未知的研究方法等著我去嘗試，就足夠令人興奮了！

回想早期放在作品集中的課堂報告，總是將 Redesign 的方向拘泥於華麗好看的介面設計，卻忽略前期質性與量化研究的重要性，現在回頭看都是滿滿的黑歷史。

其實透過研究，才能讓我們更貼近使用者的需求，透過測試與迭代去驗證我們的設計方案，進而尋找最佳解決辦法。

因為時程的關係，很可惜沒能參與到後續的開發與成效追蹤，也沒辦法將設計方案做後續的迭代驗證，未來有機會的話，希望能夠補足這一塊經驗，使我成為更加純熟的設計師 🙌

最後，感謝看到這邊的各位！如果覺得這篇文章對你有幫助，請拍拍手讓我知道，會成為我持續學習與分享的動力👏有任何的建議與想法，也歡迎留言與我交流指教～

※本文由 Millie Qiu 授權勿任意轉載，原文《國泰人壽 Product Design 實習：官網預約顧問功能優化》

這篇文章 【學長姐帶路】國泰人壽 Product Design 實習心得 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《2024 年軟體工程師的價值是什麼？會不會被 AI 取代？》

文/Judy Tsai

今年很榮幸有機會參與曼陀號計畫並加入 Engineering 組，從海選時就感受到這裡匯聚了很多優秀的人，雖然很多人都謙稱自己還有點迷惘，但其實都對於生涯規劃很有想法，也樂於學習新知、參與社群，感覺在這個群體裡能激盪出很多火花、觀點與可能性。

⛴️ 曼陀號計畫簡介：
所有人員皆以志工形式參與，為期約六個月，邀請各領域知名專家擔任小組船長 (Mentor)，分組舉行實體聚會。透過船長的專業分享與經驗傳承，幫助水手 (Mentee) 縮短摸索的成本，突破職涯上的瓶頸與挑戰，成為科技領袖人才。

感謝 Jalex 確診仍抱病分享！

終於來到引頸期盼的第一次月會，主題是《什麼是軟體工程師？價值為何？未來在哪？》。

今年 10 月我就擔任軟體工程師滿三年了，但坦白說，在這次月會之前，這些根本不是我在想的問題。

什麼是軟體工程師的核心價值？

轉職的這一路走來，我的眼光和思維都聚焦在眼前這座大山，總想著如何轉職成功？如何提升自己的知識技能以匹配我的 job description？如何從冒牌者症候群中自我調適？如何才能成為更進階的工程師？好似總想著如何爬得更高，卻忘了抬頭看上面到底是怎樣的天空？山的另一頭又潛藏著什麼樣的挑戰與風景？

軟體工程師的價值是什麼？原本想說大概就是「用軟體解決問題」吧！如今透過 Jalex 的觀點，進一步完整了我對這個議題的認知。他認為軟體工程師擔任的角色是要判斷問題能否被解決 (feasibility) 及如何解決 (solution)，並當責 (accountable)，而價值分為兩個面向，一是解決問題，為公司帶來收益、二是說服他人問題無解，進而為公司減低風險與成本。

我覺得「說服他人問題無解」似乎是比較容易被忽略的價值，通常想像中厲害的工程師就是不管再難的問題都辦得到，像電影裡面的天才工程師，一個需求進來，咻咻咻就寫出厲害的程式，拯救全世界。但如果工程師總是所有需求照單全收，那會不會有點像工具人了？如果公司招募一位工程師只是要寫 code，其實近年已經發展出許多不需任何程式碼也能達成目的的服務和工具，若真要寫程式，當今的 ChatGPT 也能幫上不少忙。

Jalex 引用了這句令我印象十分深刻的話：

Never be eager to say no. But also, never be afraid to say no. You see, you were hired for your ability to say no. Anybody can say yes. But only people with skill and knowledge know when and how to say no.
- Chapter 14. Teamwork, Clean Craftsmanship: Disciplines, Standards, and Ethics, Robert C.

比起 say yes，say no 所需具備的背景知識、能力、眼界門檻是更高的，你需要同時具備 domain knowledge、熟悉公司 business logic、了解哪些是 spec 不能動、哪些東西不能說改就改、說刪就刪、哪些又是可以彈性調整……，全盤考量掌握這個問題與潛在解決方案帶來的影響面向、範圍、程度、是否有 edge case 或是 side effect 需要評估？除了單純會寫程式，更是那些專業知識、經驗、洞見讓你有能力評估風險並且 say no，能為公司省下大量成本與風險，也是邁向資深工程師的其中一個重要軟實力。

say no 很像是某種特權，因為你夠專業、考量的夠周到，所以人們信賴你，但同時你也需要為結果當責。好好回答一件事情可不可以做，是軟體工程師的價值——說到這裡，有沒有發現其實不只需要會寫程式？

「為此，我們必須技術、溝通力兼具。」 — — Jalex

什麼是軟體工程師的影響力？

「影響力」一直是我比較不擅長的思考方向，常常忽略自己做的事情究竟帶來哪些影響，因此月會中 Jalex 對於這方面的分享對我來說是個新的思考起點，他描述到三個面向：

工程面

• 以身作則的能力

不是成為了資深工程師、職級提升之後就雙手一攤，變成只出一張嘴，而是要 lead by example，透過親身示範，為團隊成員樹立標準，讓自己成為他們的榜樣（role model）。唯有接地氣、了解任務細節，才能贏得夥伴的尊重，成為有影響力的領導者。

• 突破未知的能力

沒有人能夠通曉萬事，總會遇到陌生問題。優秀的軟體工程師懂得在困境中剖析問題、不排斥學習新知，在必要時跨出舒適圈嘗試新的解決方案，甚至能進一步為團隊夥伴帶來啟發，激發更多可能性。

• 槓桿時間的能力

意指所開發的內容，不只是為了交付當下的需求、解決眼前看到的問題，而是尋求長遠的影響，對於技術、產品甚至整間公司帶來長期的益處。

Jalex 建議我們可以常常去思考：有什麼事情是我們離開後，還能持續為夥伴、公司帶來價值？也許是建立一個 CI/CD 流程、也許是模組化程式碼，盡可能做一些能帶來長期好處的事，對於自己和公司都有幫助。

這個概念源自 Amazon 這句話：

“Deliver Results” is a low bar for a Principal Engineer. Without seeking the spotlight, Principal Engineers make a lasting impact that echoes through the technology, the product, and the company.
- Principal Engineering Community Tenets, Amazon

產品面

Jalex 引用了 Double Diamond 模型來說明軟體工程師在產品面的影響力，圖中上方的四個階段由左到右分別可以解釋成產品發想（Discover）、需求收斂（Define）、系統設計（Develop）、開發交付（Deliver），剛好是一個產品誕生的時間軸。

而 Junior 和 Senior 工程師的影響力順序恰好反過來，越 Junior 的工程師越貼近開發交付，然後漸漸往系統設計、需求收斂靠攏，從貼近產品（Solution），到貼近產品在解決的問題（Problem）本身。

我認為這一段可以理解成：要越來越懂 PM 在想什麼。

因為 PM 對於程式碼的實作細節通常不太熟（也不太需要），恰好提供工程師換位思考的機會，可以常常練習在與 PM 對話時觀察、體會對方關注的重點是什麼，有助於工程師理解這個產品為什麼會誕生、為何這樣設計、解決哪些痛點、使用者是誰等等，一旦對這些圖中左半邊的事情熟悉了，其實無形中也會幫助到右半邊的系統設計與開發交付，至少就不會寫出違背產品邏輯的程式碼。

再者，也許你也不一定想一輩子都當工程師，平時多培養產品思維，有助於思考更全面，實現更多可能性，未來一定派得上用場。

組織面

「現代軟體公司的核心是人。擁有足夠數量的人才，公司才能用較低的成本槓桿未來」Jalex 說。既然「人」是如此重要，讓好人才加入、避免好人才離開就成為重要的議題；能對重要議題有貢獻，就是發揮影響力了。

對於組織（公司）而言，軟體工程師影響力可以透過 Technical Branding 來體現，又可以分為外部和內部：

• 吸引外部人才

提升組織形象，吸引人才對組織的關注，甚至加入組織。這裡我問 Jalex 工程師是否需要經營自己在網路上的形象，例如寫技術文章、經營部落格、參與社群活動？他的回答是肯定的。他認為這些對於公司來說有幫助，影響力越大、公司也越容易被看見，是職涯到了一個階段後無法不做的事情。

• 留住內部人才

最有效的方式就是 mentorship，或是營造一個分享技術的團隊文化，不斷為團隊注入新知、帶下新方向，確保成員一直有成長、一直知道自己在做什麼。讓人才變強，團隊就變強；留在公司裡還能夠一直變強，想離開的機會就降低了。

我的三個觀點

身邊認識的資深工程師還很少，這是我第一次有機會近距離聽到 Staff Engineer 分享，還能及時發問互動，真的是很寶貴，也很感謝曼陀號舉辦了如此有意義的月會。

期待接下來的活動之外，我也來分享幾個自己的觀點做結：

一、遊戲化思維，是不畏懼改變的關鍵

價值是動態變化的。以前有價值的事情，現在的價值可能已不如以往，相對的，現在的價值也很可能是幾年前尚未誕生或意想不到的，唯一不變的事情就是世界一直在變，也許這就是活在這世上有趣之處，如果都沒有創新，生活應該會變得很枯燥乏味吧。

既然如此，何必焦慮呢？與其讓必定發生的改變影響心情，不如著眼於「如何讓自己跟得上這些變化」，保持開放的心胸、持續學習的心態、接觸不同的人群，這些之所以成為老生常談，也許就是因為很容易被忘記，可以每隔一陣子都去檢視自己是否仍然在各種面向接觸新知。

如果你說「我也知道要持續學習呀！但好怕自己的學習能力跟不上時代改變」，不如想想十年前智慧型手機剛開始發展時，你有在擔心自己學不會使用智慧型手機嗎？還不是玩憤怒鳥、水果忍者玩得很開心（不小心把自己做過的事說出來）？現在還不是用得好好的？

假如隨著年紀漸長，學習能力將不如以往是你的擔憂，那我覺得你可以想想過去自己是怎麼「玩手機」玩到熟悉的、再看看現在那些手機用得很好的長輩們為什麼能夠無痛適應（對他們而言的）新科技，其實會發現一個共通點，就是「玩玩看」的心態！

手機用得好的長輩傾向覺得「雖然不知道這按鈕是什麼，反正按按看也不會爆炸」就自然地從結果中學習；十年前的年輕人，也是從「試試看這玩意有什麼功能、能帶給我什麼好處」的心態出發。當今的 AI 就彷彿十年前的智慧型手機，而未來也必定會有層出不窮的新科技發表，我認為只要始終保持著遊戲化的思維，就不需畏懼改變。

二、會被淘汰的是技能，而非職業

根據我個人的觀察和淺見，技能會隨科技進步而被淘汰，例如在文件需要手寫的年代，文書處理需要的技能可能是寫出工整字跡、能快速寫出大量字數，但到了現在需要手寫文件的工作已經很稀少，因為 Word 等等文書處理軟體問世，「使用電子文書處理工具」這項技能就取代了（或者說漸漸淘汰）原本手寫文書的技能。

但職業卻不那麼容易被淘汰，因為職業始於人類需求，而需求通常不太會減少，反而是越來越膨脹（By the way 社會學有個文化工業理論在討論人的需求是如何被刻意塑造，蠻有意思的）。沿用同個例子來說，自古至今「用文字記錄事情」都是不變的需求，從古埃及就有抄書吏這種官位，相信不用我多做舉例。

因此，我認為不太需要擔心自己的職業是否會消失：

一，即便會，可能也沒有辦法消失得這麼快，畢竟一個職業的誕生與消失是整個社會共同在承擔實驗的風險，說不定在你有生之年都不會發生。

二，這可能是個假議題，真正要讓人上緊發條的是如何跟上這世代所需要的技能。

三，看準自己職業本質上滿足了人類的哪種需要？假如那種需要不會消失，那麼你的工作也將會保持一定程度的價值。

三、保有提出解決方案的能力，就不容易被淘汰

承接上一點，如果你認為人生是場有限賽局，那麼你的人生目標就會專注於如何贏得比賽，會令得失心變得很重、隨時深怕自己輸給別人而活在比較之中，活得非常辛苦。

相反地，如果你看待人生是無限賽局，沒有輸贏，那焦點就會變成如何享受比賽，甚至戳戳看各種遊戲規則會發生什麼事。這概念讓我相信無論世代如何變遷，始終要去思考「如何讓自己留在這場比賽」，只要總是有屬於自己的答案，基本上就不用太擔心自己會被機器取代。

AI 只是工具，如果人在做的事會被工具取代，那代表人要去做更有價值的事，找到那個價值在哪裡，就是留在賽局的方法。價值的具體實現，就是為問題提出解決方案。

AI 的發明，當初也是某人想出的解決方案。你和我也可以這麼做：找到一個自己有熱情的領域、再找出一個迫切想解決的問題、想出一個解決方案，就成了屬於自己的創業題目。

※本文由 Judy Tsai 授權轉載, 原文:《2024 年軟體工程師的價值是什麼？會不會被 AI 取代？》

這篇文章 【學長姐帶路】軟體工程師的核心價值是什麼？ 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《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 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《[鼠年全馬鐵人挑戰]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 實現完整應用程式開發到自動化部署過程 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《【資安工具】10個檢測惡意網址與檔案分析平台 (10 Free Online Virus Scanner Tools)》

文/Peter Zhang

現今企業日常資安防護中，都會建置/購置端點防護軟體、垃圾郵件過濾服務等，但這些措施面對企業內部「日常往來的郵件」、「資安意識薄弱使用者行為」始終無法完全100%避免使用者開啟惡意郵件檔案或惡意連結，以致最終發生資安防護系統偵測到異常行為或告警時都(IT/資安單位: ...)。

有鑑於此，資安/網管單位總是會定期辦理「資訊安全教育訓練」，為讓使用者了解基礎資安知識與新聞，最終目的皆是為提升使用者資安意識，以提升判斷哪些是具高風險的郵件附檔、連結、簡訊!

當然第一線單位收到使用者反映釣魚郵件或可疑網址時，總是會請資安單位協助判斷郵件附加的短網址或檔案(.pdf/.doc/.xlsx/.pptx/.txt/.jpg等)安全問題。

因此本篇受眾族群主要專注在於「第一線IT/資安夥伴」在有限時間下，如何協助使用者透過本篇提到10項線上檢測平台迅速判斷可疑附檔、網址、IP的疑慮。

*當然這邊還是先強調，工具只是協助使用者作為判斷依據，不代表檢測結果一定是100%安全*

1. VirusTotal: https://www.virustotal.com/gui/home/upload

檢測項目:網址、檔案、網域、IP

這是一款在IT界無人不知曉的惡意檢測平台，可以檢測病毒、木馬和各種惡意軟體分析服務，其集結眾多資安業種搜尋引擎，以強化整體的檢測可行性。

VirusTotal除了可以告知使用者檢測的網址或檔案是否是惡意程式的可能，同時也提供視覺化來顯示分析結果，能讓使用者了解惡意網址、檔案或網域的關聯性。

VirusTotal實際操作結果:

Step1. 輸入欲檢測網址、IP等

Step2. 檢視分析結果

Step3. 檢視細部分析結果

VirusTotal進階分析結果:

VirusTotal具有非常多附加功能，基於本篇主要說明基礎運用，故不會提太多細部分析功能說明。

Step1. 圖形關聯分析平台功能，須從使用者依分析結果中進行點選，才會產製進階分析，如下圖請點選「地球連結圖示」。

Step2. 這邊你可以看到「原先網址分析的基礎關聯資訊」。

Step3. 左側可以檢視「原先網址分析的關聯性」與其他進階關聯性分析結果，包含網域資訊、IP位置、其他有關感染的網址、惡意檔案等細部資訊。

綜上針對VirusTotal進階分析僅提及到這，詳細的分享預計日後會獨立一篇分享VirusTotal細部的功能。

2. Cisco Talos: https://talosintelligence.com

檢測項目:網址、網域、IP、資安情報(漏洞趨勢、資安新訊等)

圖片來源: https://blog.talosintelligence.com/

Cisco旗下的Talos Intelligence Group 是目前世界最大的商業情報威脅團隊之一，其主要保護Cisco客戶免受已知以及未知的新威脅攻擊，同時Talos團隊也是目前維護知名的開源軟體Snort、ClamAV與SpamCop官方相關套件貢獻者。

Cisco Talos實際操作結果:

Step1.輸入欲檢測的目標資料

Step2.檢視分析結果

3. MetaDefender Cloud: https://metadefender.opswat.com

檢測項目:網址、檔案、網域、IP、CVE

OPSWAT是一家全球知名的資安業者，主要專注領域在網頁清洗（Web CDR）、檔案深層掃描與清洗（CDR）、郵件清洗（Mail CDR）等服務。

OPSWAT實際操作結果:

Step1.輸入欲檢測的目標資料

Step2.檢視分析結果

4. IBM X-Force Exchange: https://exchange.xforce.ibmcloud.com/

檢測項目:網址、檔案、網域、IP、CVE、#tag資訊搜尋、資安情報(漏洞趨勢、資安新訊等)

IBM旗下的X-FORCE Exchange 是一款SaaS級免費的威脅平報分享平台，用於快速研究最新的資安威脅、彙整最新情資與專業資安專家協同合作進行情資分析工作，以此提供使用者防範最新的資安威脅。

IBM X-Force Exchange實際操作結果:

Step1.輸入欲檢測的目標資料

Step2.檢視分析結果

5. FortiGuard Web Filter Lookup: https://www.fortiguard.com/webfilter

FortiGuard Online Scanner: https://www.fortiguard.com/faq/onlinescanner

檢測項目:網址、檔案

Fortinet旗下的FortiGuard Labs目前有提供2款線上檢測平台，實際操作結果:

第1個Web Filter Lookup是檢測網址(平台內所提供的網址評論會在24小時內進行處理與更新)。

Step1.輸入欲檢測的目標資料

Step2.檢視分析結果

第2個Online Scanner是檢測檔案安全性(目前檔案最大上傳限制為10MB)。

6. Trend Micro Site Safety Center: https://global.sitesafety.trendmicro.com

檢測項目:網址

Trend Micro(趨勢科技)所提供的Trend Micro Site Safety Center，主要以網站的評級進行評分分類，其會以網站創立的時間、歷史位置與變化以及結合自有的惡意軟體行為分析來進行檢測可疑活動跡象。

Trend Micro Site Safety Center實際操作結果:

Step1.輸入欲檢測的目標資料

Step2.檢視分析結果

7. Palo Alto Networks URL Filtering:

檢測項目:網址

Palo Alto Networks是知名的次世代防火牆，也是Gartner評定為2022網路防火牆品牌中的領導者。

Palo Alto Networks 所提供的URL Filtering功能，其資料庫是來自於自家所建立的PAN-DB URL，同時會比對過濾網址中的信譽/風險等級、網域歷史記錄分析、自有的機器學習式網路分類功能等。

Palo Alto Networks URL Filtering實際操作結果:

Step1.輸入欲檢測的目標資料

Step2.檢視分析結果

Palo Alto Networks URL Filtering功能目前沒有提供檢測方式或檢測標準資訊，依自己目前使用其他檢測平台後，確實顯示結果較陽春，不過整體檢測結果也都蠻準確的(這是最重要的XD)。

8. Zscaler Zulu URL Risk Analyzer: https://zulu.zscaler.com/

檢測項目:網址

Zscaler是一家雲端網路安全公司，主要以SaaS方式提供資安服務，也是被Gartner評定為2022安全性服務邊緣(Security Service Edge)廠商的領導者。而Zulu URL Risk Analyzer平台提供即時檢測可疑網址與網址信譽紀錄服務，同時也提供細項檢測說明，如URL Information、Analysis Results(即時執行分析結果)、External Elements(相關網站關聯性檢測)、Content Checks與Host Checks等。

Zscaler Zulu URL Risk Analyzer實際操作結果:

實際使用Zscaler Zulu URL Risk Analyzer中，除了會比對既有惡意程式資料庫外，同步會針對該網址進行深度內容分析，以致需要等待一些時間。

Step1.輸入欲檢測的目標資料

Step2.檢視分析結果

9. FileScan.io: https://www.filescan.io/scan

檢測項目:網址、IP、網域、檔案

FileScan.io是一個免費檢測惡意軟體或網址平台，可以快速針對使用者所想檢測之內容進行深度分析，進而產製檔案分析細節、網址/網域分析細節、入侵威脅指標 (Indicators of Compromise, IOC)、其他檔案相關性分析、OSINT搜尋結果、地理位置等。

然而2022/10由OPSWAT宣布收購FileScan，同時該團隊成員也加入OPSWAT公司中，進而擴大OPSWAT旗下的惡意程式分析平台深度與精準度。

補充小知識:

入侵威脅指標 (Indicators of Compromise, IOC)是協助作為主機或網路上遭入侵的取證之依據。

然而專業的資安人員或系統管理人員會特別注意以下指標依據:
1.異常流量進出網路
2.系統中的未知檔、應用程式和流程
3.管理員或特權帳戶中的可疑活動
4.非正常活動，如在組織不與之開展業務的國家/地區的流量
5.可疑的登錄、訪問和其他網路活動，表明探測或暴力攻擊
6.公司文件中請求和讀取量異常激增
7.在異常常用埠中穿越的網路流量
8.篡改檔、功能變數名稱伺服器 （DNS） 和註冊表配置以及系統設置（包括行動裝置中的更改）的變化
9.大量的壓縮檔和數據無法解釋地發現在它們不應該的位置

參考資料:
1.https://www.trendmicro.com/vinfo/us/security/definition/indicators-of-compromise
2.https://choson.lifenet.com.tw/?p=218

FileScan.io實際操作結果:

Step1.輸入欲檢測的目標資料

Step2.檢視分析結果

FileScan.io分析結果如下圖30所示，共有7個掃描結果頁籤，其中有針對檔案、網址等提供更進一步的分析結果。

本篇中僅針對網址進行安全性分析，故僅點選「URL Details」檢視網址深度分析結果資訊，如圖31所示

10. Google資訊公開報告-網站狀態: https://transparencyreport.google.com/safe-browsing/search

檢測項目:網址

圖片來源: google 資訊公開報告網站

Google資訊公開報告現況提供使用者了解政府機關、企業政策行動，如何影響隱私權安全性與資訊傳播性。除此也透過Google既有的「安全瀏覽」技術每日檢查數十億個網址，找出不安全的網站。這也是後期使用Google Chrome時，會自動跳出偵測與阻擋不安全網站功能之依據。

Google安全瀏覽實際操作結果:

Step1.輸入欲檢測的目標資料

Step2.檢視分析結果

下圖表為彙整本篇提到的10個線上檢測平台彙整比較資訊。

綜上提到了10項檢測可疑網址與檔案平台，能協助第一線的網管、資安夥伴或是使用者可先行自我檢測與判斷是否安全，但還是得強調現行的資安攻擊方式百百種，所有檢測工具都是基於既有的知識庫與已知攻擊行為進行分析，因此工具分析結果僅是作為判斷依據之一，無法100%保證無害。

額外補充:

先前曾介紹一套SpiderFoot HX是一套OSINT工具，該工具被歸類於紅隊演練工具之一，如下方連結文章所示，可以透過既有已知的一些資訊進行關聯性搜尋與比對，如郵件寄件人、IP、姓名、社群媒體、暗網資料等，以找出相關性，如黑名單網域、惡意IP、釣魚網址、網站漏洞等資訊，利於資安人員可以快速判定寄件人資訊是否有問題。

(前提須具有一定知識與資源(錢)才能有效利用SpiderFoot HX回饋資訊進行後續判定與新增相關防護措施)。

【滲透測試LAB】如何使用OSINT — SpiderFoot 執行情蒐

參考資料:

1. Cisco Talos
2. IOC
3. VirusTotal
4. MetaDefender Cloud
5. IBM X-Force Exchange
6. FortiGuard
7. Trend Micro Site Safety Center
8. Zscaler Zulu URL Risk Analyzer
9. Palo Alto Networks URL Filtering
10. FileScan.io
11. Google資訊公開報告-網站狀態

※本文由 Peter Zhang 授權勿任意轉載，原文《【資安工具】10個檢測惡意網址與檔案分析平台 (10 Free Online Virus Scanner Tools)》

這篇文章 【學長姊帶路】10個檢測惡意網址與檔案分析平台 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

原標《AWS的雲端架構框架-資安篇》

文/Cancerpio

目前很多服務都有提供API Webhook的功能，當事件發生時，就可以把事件的資訊送到我們指定的目的地 。

例如:我們可指定Git在commit時，通知CICD工具做自動測試 / 部署，以及LineBot在收到聊天訊息時，把訊息內容送到我們指定的API Endpoint (也就是API的網址)，做進一步的程式處理。

而當測試這些Webhook功能，或者拿來開發最小功能產品(MVP)時，雲端Serverless服務是一個方便快速的方式 ，例如AWS Lambda。

AWS Lambda

需注意的是，剛開始接觸AWS服務架構時，點進去的架構圖有一個”Add Trigger”的選項，容易讓人誤以為API Gateway和Lambda這兩個服務是綁在一起的:

Function URL

但其實Lambda自身就有提供Function URL的功能， 不必加上API Gateway這個trigger，也能供外部以API Calling的方式，來把需要的資訊讓Lambda Function接收到。

API Gateway的限制

相較於Function URL API Gateway在被外界存取時，一定要透過IAM(AWS的身份驗證)，較不利於專案初期的測試，例如只是想簡單的測試Linbot發出的Webhooke Event

要讓Lambda function用非IAM驗證 / 無驗證的方式開放給外界使用時，可以設定Function URL來快速的測試Webhook。

設定Lambda Function

• 點擊Configuration 分頁, 在左側欄的Function URL設定

測試

在Line developer platform 點擊Verify去驗證API

使用API Gateway Endpoint測試Linebot webhook

會出現403 Forbidden

使用Lambda Function

如上圖，使用Lambda Function產生的URL就可以成功被Verify了。

※本文由 Cancerpio 授權勿任意轉載，原文《[AWS]使用 AWS Lambda快速串接LINE Bot: Webhook》

這篇文章 【學長姐帶路】使用 AWS Lambda快速串接LINE Bot: Webhook 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。