只有累積,沒有奇蹟

2022年6月15日 星期三

[AzureDevops] 初探 Wiki 文件管理

前言
隨著團隊成員越來越多,在人員越來越多發現有些基本知識像是 Code Review 規範或是新人報到流程沒有系統化整理起來,因此需要一個知識管理平台存放相關 Domain 與流程相關文件,於是開始 suvery 知識管理平台發現在 Azure Devops Wiki 符合好管理、版控紀錄、可以使用 markdown 方式撰寫十分方便,可以做為團隊上 KM (knowledge management) 文件中心,這篇文章就來簡單介紹小小的使用心得。

建立 Wiki Project
首先在 Azure Devops 建立完 Demo Team Knowledge Management 專案,接著建立 wiki 專案,到左邊點擊 create project wiki
接著會請你建立第一個 wiki page,在這編輯視窗是可以透過 Markdown 格式輸入你整理好的資訊文件內容,接著就完成了第一頁 wiki page。

關閉 Azure Devops Service
建立完專案後,如果專案目的是專門給 Knowkedge Management 文件管理使用的話,可以考慮關閉專案中其他 Azure Devops Service 像是 Board、Pipeline、Test Plans 等服務,選單就會比較乾淨些。關閉方式可以透過到 Project setting > Azure Devops Service > Off service
關閉之後,在 Project 左方選單就僅會呈現必需的資訊 (非必要,視主管與團隊需求而定)

設定 Access level
建立完專案後,必須在設定用戶權限才可以具有訪問專案的權限,如果沒有特別設定的情況下預計權限會是 Stakeholder,可以訪問到的功能是 Azure Boards 和 Azure Pipelines 部分功能;要讓團隊成員可以編輯則要將訪問權限設定為 Basic,就可以讀取大部分的 Azure Devops 服務,詳細訪問級別權限與讀取服務可以參考 About access levels

Clone Wiki
在編輯上有兩種方式,你可以選擇直接在 Azure Devops 上直接透過畫面編輯,或是把專案直接 Clone 下來 (背後也是 Git Repo),Clone 功能可以透過專案點擊右邊會跳出 more action,接著選擇 Clone wiki 複製 Git repo 位置,再透過你熟悉的工具進行編輯的動作
Wiki Page
新增 page
可以透過下方的 new page 進行新增 wiki page 的動作,如果新增完頁面後想要新增子頁面也可以透過 add sub-page 動作新增,在 page title 部分是有限制的,wiki page 名字是不能重複(唯一性),不能與其他已存在的 wiki page name 重複;另外在 page title 上如果輸入空白的話系統預設會用 - 來取代。
如果要進行頁面的排序調整,可以透過滑鼠拖拉的方式在 Azure Devops 介面直接調整;若是使用 Git repo 則可以開啟 .order 檔案透過手動修改排序方式達到你要調整的排序。

Page 編輯
在編輯文字內容上是使用 Markdown 風格,關於 markdown 基本語法詳細說明可以參考微軟官方文件 Syntax guidance for basic Markdown usage,這裡就不在多加說明,這裡我就列出個人覺得實用的幾個功能
Table of content (TOC)
當你的內容需要標題時可以在指定位置插入 TOC,讓在閱讀時可以透過導引快速定位你要找的資訊內容,對於文件內容過長時很好用
Insert Mermaid diagram
如果文件中需要說明模組之間的互動關係,或是畫流程圖時,可能在過去都是透過軟體繪製,像是之前在部落格介紹過的 PlantUML - 在 Visual Studio Code 繪製 UML 圖,再將畫完的結果截圖貼在文件內容中。使用 Mermaid 則可以替你省下這些工作
舉例來說上述內容簡單描述 User 發送請求,透過應用程式讀取資料庫的流程,在 Mermaid 使用下列語法描述
::: mermaid
 graph LR;
 A[User] --> B[Application] --> C[Database]
:::
可以在編輯視窗中劃出所需要的流程圖,可以說是相當的方便。目前內建支援三種圖形分別是循序圖、流程圖與甘特圖,如果想了解更多細節內容可以參考官方文件 add-mermaid-diagrams-to-a-wiki-page 說明。

感想
工欲善其事,必先利其器。在過去開發或是接觸到不同的專案時,最讓人害怕的就是沒有文件說明要重新摸索,可能會花費較長的時間來整理前人留下來的祖產內容,但部分開發人員對於撰寫文件也是不熟悉的,如果可以讓撰寫文件這件事變得容易上手,就有機會達到這兩者之間的平衡。若是你的團隊也有類似的困擾時不妨可以參考 Azure Devops Wiki 的服務,讓知識文件化對團隊夥伴帶來幫助,hope it help :D

參考
Add and edit wiki pages
Syntax guidance for Markdown usage in Wiki


2022年6月13日 星期一

[sharing] 開發經驗分享 - Web API 從 0 到 1

分享
最近在整理筆電資料,不小心發現過去在某公司開發經驗的投影片,從一開始的建立 API Team 的緣由到後續遇到諸多線上 Production 問題的寶貴經驗,從無到有在到上線後的效能問題,再來思考如何建立監控機制來確保 API 的穩定性與問題追蹤,或許這些解決方案在現在可能都是 common sense 但在當時年少無知時是加班熬夜很多個夜晚所解決的,現在回想起來都是挺有趣的但是在問題發生當下是辛苦的,在整理完後當時在前公司 T 社也有分享給全公司的夥伴交流,希望有些踩過的雷年輕的夥伴們不要再重複遇到,提供給有興趣的朋友也希望可以幫助到各位 :)

2022年6月4日 星期六

[Azure] App Service Diagnostics - Collect Memory Dump

前言
前兩篇分別介紹了 App Service Diagnostics 中的 Collect .Net Profiler Trace 與 Auto heal,分別都可以透過工具來蒐集雲端伺服器的緩慢問題分析與蒐集記憶體資訊,這一篇則是介紹如何 dump 目前伺服器 memory 的資料,以及有多個伺服器的時候該如何抓取特定的 Server memory data。若對於上述內容有問題或是不清楚的地方,歡迎提出來一起討論。

Collect Memory Dump
在 Azure 上提供非常多的分析工具可以協助開發人員找到應用程式的問題,應用程式出問題不管在地端的機房或是雲端上都是有可能會發生的,在過去服務還沒上到雲端時是透過一些工具,像之前黑暗大就寫過 ASP.NET CPU 飆高問題之傻瓜分析工具-DebugDiag Tools 找到應用程式 Crash 或是緩慢原因,今天要分享的是 Memory Dump 把應用程式當下的記憶體 clone 一份下來,再進行問題的盤查或是分析,另外在 Memory Dump 之前提醒事項如下
  • While collecting the memory dump, a clone of your app's process is created so the impact on the site availability is negligible.
  • Dumps are collected for the worker process (w3wp.exe) and child processes of the worker process.
  • Size of the memory dump is directly proportional to the process size, so processes consuming more memory will take longer to be dumped.
  • Your App will not be restarted as a result of collecting the memory dump.
白話來說,Memory Dump 會 Clone 當下應用程式 (w3wp.exe) Process 的資訊,花費時間多寡取決於 Process 用量多寡決定,應用程式不會被重啟。了解以上資訊後,就來看看如何在 Azure 設定 Memory Dump
Step 1 : 開啟 App Service
Step 2 : 點選左邊清單的 Diagnose and solve problems 功能
Step 3 : 在右邊框輸入 "點選 Memory Dump"
Step 4 : 選擇 Dump 下來的檔案放置的位置,如果之前沒執行過需要設定 Dump file 要存放的位置
Step 5 : 接著下一步,Mode 部分是選擇要蒐集 Dump Data 或者是除了 Dump 之外還希望進行 Memory 的分析,如果 Server 是多台機器的話,下面會列出目前的機器有哪些提供使用者選擇所要蒐集的 Instance
另外,如果之前有執行過蒐集過 Dump 的動作,下方也會列出之前手動或是自動蒐集的 Dump 檔案清單
Step 6 : 按下 Collect MemoryDump 按鈕之後,會開始蒐集應用程式的 Memory 資訊 (需等待一段時間,時間長短跟你應用程式 Memory 成正比)
Step 7 : 完成後可以看到 dump file 存放到指定的 storate account 位置,如果有勾選 Analyze Data 則會產生分機報告。
Step 10 : 點選 Report 可以看到分析 memory 的結果,打完收工 !
另外,如果是在線上環境發生緊急問題時,蒐集應用程式的 Memory dump 可以有助於我們找到問題,但其 dump 處理時間是很漫長會花費比較長的時間,勢必也會影響到處理線上問題的時間,與微軟技術支援討論建議如果遇到這狀況,可以透過 Metric Apply Splitting 找到特定的 instance,接著在 dump 時選擇該 instance 加速其 collect dump file 的時間 (又多學到一招,Azure 初學者覺得開心)。

結論
以上是簡單介紹 Azure Memory Dump 的方式,另外在微軟官方 youtube 也有影片說明如何在 App service 進行 debugging memory 的說明,有需要的朋友可以自己觀看,Hope it helps :D

Copyright © m@rcus 學習筆記 | Powered by Blogger

Design by Anders Noren | Blogger Theme by NewBloggerThemes.com