SAS 系統管理 (103)

教學目標

初步了解如何解決 SAS Enterprise Guide 長時間處理大量資料發生連線中繼的錯誤問題。

重點概念

首先在企業使用 SAS 軟體的我們習慣透過 SAS Enterprise Guide 整理資料,並且產生 SAS 資料集,以利進行統計分析或模型建立等資料科學人工智慧相關實務應用,但是關鍵在於資料且是大量的資料,此時就會發生當 SAS Enterprise Guide 執行 SAS 程式碼超過半小時以上的時間之後,我們將會發生非預期的錯誤無法針對所要求的資源建立連線導致無法正常產生分析結果的資料表,這將會對於業務單位使用 SAS Enterprise Guide 時造成很大的困擾。

接著我們要如何解決上述問題呢?一開始我們先了解 SAS Enterprise Guide 無法在沒有使用者操作的情況下啟動中斷連線,但是有幾種情況可能會造成連線中繼,主要有三種,分別為:

  1. 網路不穩定 (Network instability):如果客戶端和伺服器之間傳輸的資料包遺失,此時 SAS Enterprise Guide 與 SAS Metadata Server 之間的連線可能會被切斷,從而產生先前描述的錯誤。
  2. 防火牆超時 (Firewall time-outs):當連線保持空閒狀態時,可能會由防火牆中繼空閒連線,如果長時間執行的作業始突然中繼連線,或者 SAS Enterprise Guide 長時間處於打開狀態,則中斷連線將可能來自於防火牆使用空閒連線超時的設定。
  3. 工作站上設定省電模式 (Power-saving modes set on the workstation):Windows 作業系統個人電腦在指定的不活動時段內進入低功耗狀態的情況,這種行為經常發生在筆記本電腦上,如果執行 SAS Enterprise Guide 的個人電腦進入低功耗狀態,則可能已禁用網路卡以節省電量,此時若發生這種情況 SAS Enterprise Guide 與中繼資料伺服器之間的連線將會遺失。

而 SAS Enterprise Guide 主要連線兩個連接埠,分別為中繼資料伺服器 (8561) 和工作區伺服器 (8591),當作業運行很長時間時,雖然 SAS Enterprise Guide 和中繼資料伺服器和工作區伺服器在連接埠上連線保持活動狀態。但是中繼資料伺服器連接埠在作業執行時處於空閒狀態,如果設定傳輸控制協議(TCP)超時以中斷空閒連接,則會中斷它,如果防火牆是中斷連線的根因,則可以透過增加為防火牆設置的超時間隔來阻止中斷連線的發生。

再來我們可以在工作區伺服器上設定 keepalive 參數,以利確保防火牆不會中斷不活動的已連接的客戶端, 所謂 keepalive 參數主要是定期向非活動的客戶端發送事件包,以防止網路防火牆中斷連線,其中事件包的間隔主要以秒為單位,最小值為 30 秒,零值將關閉 keepalive 參數,至於修改步驟為:

  1. 開啟「SAS Management Console」工具,登入「sasadm@saspw」帳號密碼。
  2. 在「Server Manager」->「SASApp」->「SASApp - Logical Workspace Server」上按右鍵選擇「Properties」。
  3. 在「Option server parameters」參數中輸入「keepalive=300」代表每五分鐘發送事件包防止網路防火牆中斷連線,按下「OK」。

當設定完成上述設定之後,我們需要關閉再重新啟動 SAS Enterprise Guide 才會生效,以利我們透過 SAS Enterprise Guide 長時間處理大量資料,此外請注意最新版本的 SAS Enterprise Guide,現在預設超時為 30 分鐘,所以 keeplive 的時間必須小於 30 分鐘,至於 SAS Enterprise Guide 的超時可以在 SAS Enterprise Guide 的「Options」->「Data」->「Performance」中勾選「Close data grid after period of inactivity (specify in minutes):」,輸入超時時間以分鐘為單位進行修改 。

最後 SAS Enterprise Guide 無法重新建立與中繼資料伺服器的新連線,若要維護使用者的連線,則 SAS Enterprise Guide 必須保持與中繼資料伺服器的連線,若是該連線中斷就無法重新建立連線,並且發生錯誤,以及 SAS 日誌無法提供有關中斷原因的任何資訊,因為當連線中斷時 SAS 日誌只能顯示連線已中斷。

相關資源

專案管理 Scrum (5)

教學目標

初步了解 Scrum 框架的基本概念。(此篇屬於課程心得筆記分享)

重點概念

首先今天剛上完兩天的 Scrum Master 課程一收信就參加測驗滿分 (100%) 通過,取得Certified Scrum Master 證書,主要是上 Vernon Stinebaker 老師的 Scrum Master 長宏課程,老師針對 Scrum 框架的概念教得非常淺顯易懂,同時也分享許多實務導入 Scrum 的經驗,還分享幾本幫助我們未來在導入 Scrum 時可以參考的課外讀物,主要有兩本我印象深刻,分別為:

  1. Start With Why: How Great Leaders Inspire Everyone to Take Action
  2. Powerful: Building a Culture of Freedom and Responsibility

第一本書籍主要是在第一天時老師所分享為什麼要導入 Scrum,其明確的目標為在最短時間內達到最高的商業價值,至於做任何事情皆會由為什麼來驅動,而 Start With Why 書籍作者 Simon Sinek 就提出黃金圈理論,黃金圈最外層為做什麼 (What)、中間層為如何做 (How) 和核心層為為什麼做 (Why),若要導入 Scrum 框架至企業之前請先想清楚為什麼做?至於 Scrum 框架要如何做和做什麼,老師則建議參考 Scrum.org 網站中的文件。第二本書籍主要是在第二天時老師所分享自管理開發團隊要如何選對人,則建議參考 Powerful 書籍,請注意在 Scrum 團隊中並沒有經理的角色,所有團隊成員皆是平等,這與現行企業組織文化衝突,至於 Scrum Master 僅負責引導開發團隊了解 Scrum 框架和移除障礙,而產品擁有者僅有權力管理產品待辦清單,而沒有權力管理短衝待辦清單,只有開發團隊才有權力管理短衝待辦清單,此外開發團隊還有責任發佈產品的增量,至於開發團隊的成員則建議找 T 型人才達到跨職能的團隊,才能擁有產出產回增量所需要的所有技能,此時若要找到最適合開發團隊的人才就會是一大挑戰。

接著上述所提到的 3 個角色,Scrum Master、產品擁有者和開發團隊,皆有屬性和責任,請參考下表。

角色 屬性 責任
Scrum Master 沒有權力和影響力 移除障礙
產品擁有者 一個人做決策和決定授權 願景和投資回報率
開發團隊 自管理和跨職能 發佈產品增量

若是 Scrum 團隊中有成員不了解 Scrum 框架,則 Scrum Master 需要指導讓其了解和負責移除障礙,雖然產品待辦事項主要是由產品擁有者決定,但是好的 Scrum 團隊也是能夠做決定,但是產品擁有者對於決定還是要負責,至於要如何選擇產品待辦清單中的事項,建議按照投資報酬率進行排序以最大化價值為挑選依據,但是產品擁有者最有挑戰的則是有對願景負責的責任。至於開發團隊會集體合作完成產品待辦事項,每個人理應會儘可能幫助團隊完成目標,並且團隊臨情況會快速回應,此時 T 型人才就適合創意激發,此外請注意開發團隊建議是 3 至 9 人,因為 9 人以上溝通成本將會是障礙,但是僅有 3 人就真的適合 Scrum 框架嗎?是值得思考的問題。

再來除了角色之外,還有 3 個產出物主要為產品待辦清單、短衝待辦清單和增量,請注意所謂燃盡圖和看板並非 Scrum 框架中必要項目,當我畢業在新創公司工作時主要用燃盡圖和看板,之後在銀行企業工作時僅用看板,原來燃盡圖無法像看板有效呈現問題,以利快速解決問題,因此漸漸不建議使用燃盡圖。產品待辦清單則是一個動態已排序好有可能會成為產品的動態列表,描述完成測試項,單一來源需求,… 等屬性並且僅能由產品擁有者在任何時間進行更新,我們要嘗試簡化工作代表著不去做帶來價值極低的工作,一般我們會以價值和成本進行排序,請注意有時還會考慮風險,總之如何有效挑選產品待辦事項是一門學問。短衝待辦清單主要是從迭代中挑選過來的產品待辦事項再加上能夠落實的計畫,可性高,方便追蹤進度詳細資訊,…等屬性,此時建議搭配看板方法,至於每個短衝待辦清單要如何做,則建議搭配極限編程 (eXtreme Programming,XP) 方法,像是其中的使用者故事就是最常被採用的最佳實踐,至於敏捷估算也非 Scrum 框架中必要項目,總之如何針對短衝待辦清單進行估算是一門學問。增量主要是從迭代中挑選過來已完成的產品待辦事項再加上已存在的增量,達到產品的遠景和目標,發佈或不發佈,…等屬性,請注意不一定每個迭代皆能夠進行發佈,並且若在發佈之後有任何產品缺陷包括資安議題出現,則建議列入最先需要被進行的短衝待辦清單,現在企業面臨越來越多的資安威脅,因此對於資訊安全越來越重視,因此如何修補已發佈的資安議題將會是非常重要的事項。

最後除了角色和產出物之外,還有 5 個活動主要為短衝、短衝規劃會議、每日站立會議、短衝審查會議和短衝自省會議,敏捷不是快但會提早完成,透過每次的短衝快速持續改善,請注意短衝必須小於 1 個月,短衝規劃會議小於 8 個小時,短衝審查會議小於 4 個小時,短衝自省會議小於 3 個小時和每日站立會議小於 15 分鐘,至於要如何執行 5 個活動請參考官方文件吧,等我之後有實際將 Scrum 框架應用至專案提高客戶滿意度時再來心得分享。

總結二天的 Scrum Master 課程上完我個人從老師那收獲很多,當然我在課堂上也問了一些之前工作應用不完整 Scrum 框架碰到的問題,老師有辦法回答和以自身經驗故事分享看法,真的很不錯,但是可能再過幾天我就會僅記得 Scrum 明確的目標為在最短時間內達到最高的商業價值了,這也是老師期望我們上完課之後至少深刻記得最重要的一句話。

Certified Scrum Master 證書

相關資源

專案管理 Scrum (4)

教學目標

初步了解 Scrum 框架的基本概念。(此篇屬於課程心得筆記分享)

重點概念

首先 Scrum 有明確目標為「在最短時間內達到最高的商業價值 (The purpose of Scrum is to achieve the high business value in the shortest time)。」,同時這也是 Scrum 的為什麼 (Why),至於 Scrum 的特徵主要有三個,分別為:

  1. 時間盒 (Timebox)
  2. 拉式系統 (Pull System)
  3. 問團隊 (Ask the team)

其中 Scrum 的核心是短衝,短衝則是一個月或更短的時間盒,而開發成員將會透過拉式系統從短衝待辦清單中選其一進行實作,此外當我們遇到問題不知如何解決時,問團隊就是最建議的解法。

接著 Scrum 是個框架,人們可以運用這個框架來處理錯綜複雜的調適性問題,善用生產力與創意來交付盡可能最高價值的產品,其中主要有三個角色 (Roles)、三個產出物 (Artifacts)、三個活動 (Events) 和五個價值 (Values),分別為:

角色

  1. 產品擁有者 (Product Owner)
  2. 開發團隊 (Development Team)
  3. Scrum Master

產出物

  1. 產品待辦清單 (Product Backlog)
  2. 短衝待辦清單 (Sprint Backlog)
  3. 增量 (Increment)

活動

  1. 短衝 (Sprint)
  2. 短衝規劃會議 (Sprint Planning)
  3. 每日站立會議 (Daily Scrum)
  4. 短衝檢視會議 (Sprint Review)
  5. 短衝反省會議 (Sprint Restrospective)

價值

  1. 承諾 (Commitment)
  2. 勇氣 (Courage)
  3. 專注 (Focus)
  4. 開放 (Openness)
  5. 尊重 (Respect)

再來在 Scrum 角色中並沒有經理的角色屬於自我組織,產品擁有者針對產品待辦清單有決定權,通常會按照優先權進行排序,但是無法變更短衝待辦清單,僅有開發團隊對短衝待辦清單有決定權,開發團隊不一定全是程式設計師,而是交付相關產品給最終客戶帶來價值的開發者,包括測試專家、分析師、科學家、…等,至於增量則是指在短衝期間內完成的所有產品待辦事項。

最後在 Scrum 活動中短衝的目標主要為產生可以發佈的產品總量,沒有最短期限,但是最多一個月。短衝規劃會議的目標主要為開發團隊給予合理的承諾,但是承諾若做不到不因處罰,而是從失敗中快速學習,通常迭代每周 2 小時,若失代一個月則 8 小時。每日站立會議的目標主要為確保大家對於目前情況有初步認識,主要回答三個問題,分別為昨天做什麼已完成,今天準備做什麼和有什麻障礙,小於等於 15 分鐘。短衝檢視會議的目標為產品擁有者和利害關係人去交流收集反饋,迭代每周 1 小時。短衝反省會議的目標為如何把下一個短衝做的更好也就是持續改進,小於等於 45 分鐘。

總結 Scrum 對於未導入敏捷的企業組織變革非常大,通常在既有企業組織文化很難直接套用 Scrum,當然企業也可能有許多組織內的自體組織導入很成功。

相關資源

SAS Viya (57)

教學目標

初步了解部署 SAS Visual Investigator 基本概念。

重點概念

首先在金融犯罪領域最常見的模型調整過程就是抽樣資料之後交給主題專家進行處理,以確定活動是否可疑,建立這些目標價值是調整模型的關鍵組成部分,能夠產生更有效和有效的模型,以利避免詐欺活動和識別恐怖主義融資活動,此外提供過程的可追溯性以建立模型的門檻值和權重對於檢測可疑活動的受管制方面至關重要,而 SAS Visual Investigator 不僅提供了一個用於資料探索和分析的強大功能之外,更能夠透過附加的工作流程實現分析。

接著當我們開始要將 SAS Visual Investigator 部署至 IT 內部環境時,若僅執行 SAS Viya Infrastructure Resource Kit (VIRK) 中的 Pre-installation Playbook 驗證部署環境,則在執行部署的 Ansible Playbook 時,則會發生 Elasticsearch 服務會無法啟動的問題,為了解決此問題第一步驟我們會先查詢「/opt/sas/viya/config/var/log/svi-elasticsearch/sas-elasticsearch.log」記錄檔中的錯誤訊息,第二步驟我們根據錯誤訊息推斷可能造成無法啟動 Elasticsearch 服務的根本原因,根據「max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]」錯誤訊息我們將能夠推斷需要設定「vm.max_map_count」值為「263144」,第三步驟我們執行解決根本原因的指令「sudo sysctl -w vm.max_map_count=262144」,請注意此指令設定當重新開機之後就會重置為 65530,所以需要將此指令加入至 Linux 的啟動流程中,當我們完成以上三個步驟之後,理應就能夠執行部署的 Ansible Playbook 順利部署完成 SAS Visual Investigator。

查詢無法啟動 Elasticsearch 服務的錯誤訊息

1
2
3
4
5
6
7
# cd /opt/sas/viya_1552532409/config/var/log/svi-elasticsearch
# vi sas-elasticsearch.log

[ERROR][o.e.b.Bootstrap ] [BGFsX7P] node validation exception
[1] bootstrap checks failed
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

解決無法啟動 Elasticsearch 服務的問題

1
# sudo sysctl -w vm.max_map_count=262144

再來 SAS Visual Investigator 主要是基於 SAS Viya 強大分散式資料處理和 Elasticsearch 強大的全文搜尋功能,因此我們不僅能夠部署至一台伺服器之外能夠根據客戶不同的需求,更能夠根據客戶需求將 CAS Worker、RabbitMQ、Elasticsearch Master、Elasticsearch Data 和 Postgres 分別部署至不同伺服器中進行分散式處理和提供高可用性的服務,其中我們需要特別修改 inventory.ini 和 vars.yml 兩個設定檔。 inventory.ini 設定檔重點在於 ElasticSearch_IsMaster=true 代表部署 Elasticsearch Master,ElasticSearch_IsData=true 代表部署 Elasticsearch Data,當然我們也能夠在同一台伺服器同時設定 ElasticSearch_IsMaster=true 和 ElasticSearch_IsData=true 代表同時部署 Elasticsearch Master 和 Elasticsearch Data 至同一台伺服器中,至於 Postgres 資料庫,則需要同時修改 [pgpoolc] 和 [sasdatasvrc] 設定,以及修改 vars.yml 設定檔中的「INVOCATION_VARIABLES」,否則在自動化部署時會出現「Please add sasdatasvrc variable definitions for the system named ‘XXX’」的錯誤訊息。

inventory.ini 設定檔

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

[sas-casserver-worker]
casworker

[elasticsearch]
elasticmaster ElasticSearch_IsMaster=true ElasticSearch_IsData=false ElasticSearch_HeapSize=8g ElasticSearch_QueueSize=1000
elasticdata ElasticSearch_IsMaster=false ElasticSearch_IsData=true ElasticSearch_HeapSize=8g ElasticSearch_QueueSize=1000

[rabbitmq]
rabbitmq

[pgpoolc]
postgresql

[sasdatasvrc]
postgresql

vars.yml 設定檔

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

INVOCATION_VARIABLES:
postgresql:
pgpoolc:
- PCP_PORT: '5430'
PGPOOL_PORT: '5431'
SANMOUNT: '{{ SAS_CONFIG_ROOT }}/data/sasdatasvrc'
SERVICE_NAME: postgres
sasdatasvrc:
- NODE_NUMBER: '0'
NODE_TYPE: P
PG_PORT: '5432'
SANMOUNT: '{{ SAS_CONFIG_ROOT }}/data/sasdatasvrc'
SERVICE_NAME: postgres

最後當我們部署完成 SAS Visual Investigator 之後,請先透過「/etc/init.d/sas-viya-all-services status」指令確認 SAS Visual Investigator 直接相關的關鍵服務皆有正常啟動,否則就會發生能夠登入至 SAS Visual Investigator 中,但是會發生伺服器錯誤的訊息,導致無法正常進行操作。至於 Postgres 主要是設定每個微服務的相關設定、警示訊息、內部實體、歷史選擇關係、附件檔案以及稽核記錄。

服務名稱 描述
svi-ai Visual Investigator 分析和索引服務,主要將 CSV 檔案導入至 Postgres 資料庫中的 AIUSERDATA Schema 中,並且在 Data Hub 中進行註冊。
svi-alert Visual Investigator 警示服務,主要接受警示事件和情境觸發事件,並且透過領域、策略和佇列建立和更新調查警示。
svi-audit Visual Investigator 稽核服務,主要記錄在應用程式中的使用者操作,並且為管理員提供 API 以利查詢記錄稽核。
svi-datahub Visual Investigator 資料中心服務,主要提供與實體互動的服務,其中包括實體和關係設定,檢索和儲存。
svi-elasticsearch Visual Investigator 搜尋服務,主要提供用於文本,地理空間,時間和關係搜索和內容索引的服務。
svi-entity-resolution Visual Investigator 實體解析服務,主要執行實體解析的功能。
svi-feature Visual Investigator 功能服務,主要檢索使用者所有使用功能的集合。
svi-mobile Visual Investigator 行動服務,主要提供行動相關的功能服務。
svi-network-analytics Visual Investigator 網路分析服務,主要提供用於與網路連接圖相關的中心計算和圖形化等功能。
svi-sand Visual Investigator 搜尋和探索服務,主要用於在索引,搜索和提供資料可視化功能。
svi-transport Visual Investigator 傳輸服務,主要從正在執行的實例中提供設定資料的 .zip 檔案,並且接受/部署設定資料的 .zip 檔案至系統中。
svi-visual-investigator Visual Investigator 網站服務,主要提供給客戶端網頁瀏覽器的畫面。
svi-vsd-service Visual Investigator 情境服務,主要提供情境操作的相關功能。

相關資源

SAS Viya (56)

教學目標

初步了解如何以 Python 執行 SAS Viya 平台的管理命令列介面 (Command-line Interfaces, CLIs) 解決資訊單位日常維運管理的痛點。

重點概念

首先 SAS Viya 平台提供管理命令列介面 (Command-line Interfaces, CLIs),以利我們直接透過指令的方式管理 SAS Viya 平台,而非透過介面的方式,此外我們更能夠透過 Python 呼叫 CLI 進行 SAS Viya 平台的管理操作。

接著使用 SAS Viya 的管理命令列介面,必須先設定 SAS_CLI_PROFILE 環境變數,此時我們能夠透過以下指令在 Linux 作業系統中自動設定 SAS_CLI_PROFILE 環境變數。

初始設定

1
2
# cd /opt/sas/viya/home/bin/
# ./sas-admin profile init

再來我們可以透過以下 Python 程式碼以系統管理帳號與密碼登入 SAS Viya 的管理命令列介面。

授權登入

1
2
import os
os.system('/opt/sas/viya/home/bin/sas-admin auth login -u [系統管理帳號] -p [系統管理密碼] ');

最後我們就能夠透過以下 Python 程式碼以 SAS Viya 的管理命令列介面將 Anita 這個使用者加入至業務部門的客製群組中,並且列出業務部門客製群組中的前 100 位使用者。

管理操作

1
2
3
os.system('/opt/sas/viya/home/bin/sas-admin identities create-group --id salesgroup --name Salesgroup --description "業務部門"');
os.system('/opt/sas/viya/home/bin/sas-admin identities add-member --user-member-id anita --group-id salesgroup')
os.system('/opt/sas/viya/home/bin/sas-admin identities list-members --group-id salesgroup --limit 100')

執行結果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
NOTE: Grid node action status report: 1 nodes, 8 total actions executed.
Enter credentials for http://ip-xx-xx-xx-xx.ec2.internal:

Login succeeded. Token saved.
{
"description": "Custom sales group",
"id": "salesgroup",
"name": "Salesgroup",
"state": "active"
}
The group was created successfully.
anita has been added to group salesgroup
{
"items": [
{
"id": "anita",
"name": "SAS User",
"type": "user"
}
]
}

總結 SAS Viya 平台提供管理命令列介面 (Command-line Interfaces, CLIs) 理應能夠根據 IT 資訊單位維運管理的需求進行高度彈性的客製開發自動化維運管理,以利解決資訊單位日常維運管理的痛點。

相關資源