如何進入開發服
1. 進入開發服網址，會看到需要輸入HTTP帳號，輸入HTTP帳號及密碼，即可以進入開發服。 2. 進入後台請另外輸入測試帳號及密碼。
未分類
以思科技密碼管理系統使用說明
一、開始使用 （前置項目依據公司服務開通流程辦理） 步驟一：檢查Email信箱，會收到公司信箱寄出的vaultwarden註冊邀請。 步驟二：依照指示註冊完成後，該帳號會自動被加入ApolloSome並取得「組織權限」。 步驟三：使用APP或是透過Web URL介面登入。注意事項：APP 是使用 Bitwarden 官方版本，但是需要自行設定自我託管環境，輸入Web URL即可。參考資料：APP https://bitwarden.com/help/getting-started-mobile/ 步驟四：成功登入之後要開啟二階段驗證才能正常使用。參考資料：https://bitwarden.com/help/bitwarden-field-guide-two-step-login/ 二、資料保存方式 1. 資料皆儲存於ApolloSome組織內。 2. 資料保存架構如下：－公司服務（維運團隊）－公司服務（開發團隊）－實體主機（維運團隊）－VPN（維運團隊）－專案A（專案A正式服）－－子專案A1（子專案A1正式服）－－－Dev（子專案A1開發服）－－Dev（專案A開發服）－專案B（專案B正式服）－－Dev（專案B開發服） 三、服務使用方式 1. 我的密碼庫：保存機密資料。 2. Send：傳送機密資料。參考資料：https://bitwarden.com/help/about-send/
團隊導入Bitwarden密碼管理系統
前言 大約在2021年第三季初的時候，遇到客戶端的資訊安全內部稽核（ISO27001:2013）。稽核人員有問到廠商（我們公司）內部的帳號是否有共用，當時是回覆「帳號有設定唯一的擁有者」。實際狀況是帳號透過Google Sheet的專案列表作共享，只是有特定指定擁有者，因此是有資安疑慮的。 第一次會議 2021年11月初的時候在維運進度會議上提議進行導入密碼管理系統。原因有以下幾點： 資安因素：系統應盡量避免共用帳號。目前放置於Google Sheet作共享會導致有權限的人都可以存取該表格。 資安因素：應確認所管理之系統帳號皆為合法授權者，避免出現閒置 ( 無人使用 ) 帳號或非授權使用者帳號 ( 例如職務調動或離職者等 ) 。目前放置於Google Sheet作共享會導致非專案人員也有權限存取。 工作流程優化：目前放置於Google Sheet的表單資料過多和格式混亂，查詢不易。 第一次會議決議納入優先評估項目，二周後由維運工程師在會議上提出評估結果和方案。 第二次會議 第二次會議大約在2021年11月24日，會前已經透過Slack大致討論過可行性以及製作方案（圖A：導入方案比較表），因此在會議上由維運工程師正式提出導入方案，並由專案經理確認當前團隊適合方案後提交總經理，於核准後依據導入流程進行（圖B：服務導入流程圖）。 第二次會議決議採用唯一非官方的A方案，環境建置時間大約三周（2021年11月24日-2021年12月8日）（圖C： 預期導入時程表 ） 第三次會議 第三次相關會議時間為2021年12月29日，當天會議上提出以下幾點正式導入時程： 2021年12月31日，對全部團隊發Bitwarden邀請，自行註冊。 2021年1月1日至1月14日共兩周Google Sheet和Bitwarden會並行，這段期間由維運工程師將帳號資料倒入Bitwarden，再透過專案經理指定專案權限開通。 2021年1月15日，將Google Sheet的帳號密碼列表刪除。 第三次會議決議照上述行程執行。 第四次會議 第四次相關會議時間為2021年1月5日，當天會議討論以下內容： 密碼管理系統使用率問題（團隊大概7人，有2人未註冊），決議由維運工程師協助輔導註冊和服務說明。 營運帳號保存問題。決議由營運人員自行保管，不用納入組織。 服務帳號保存問題。決議由營運人員和服務管理員共同保管。 主機帳號和專案帳號權限問題。決議由營運人員和服務管理員共同保管。 第五次會議 第五次相關會議已經結束宣導期，進行導入流程之檢討，提出以下問題： 註冊說明不清楚，有人註冊到官方版本。決議：流程新增必要使用說明文件，並於事後補充說明文件 導入過程中的通知未確實。決議：此項目為未確實執行標準流程。 這次導入規劃沒有新增到公司帳號傳送規定。決議：此項目事後補充即可，因為系統已經導入，算是附加價值。 未納入備份計畫，確認目前備份恢復計畫（演練）是否有需要調整。決議：流程要事前提出更新的服務架構圖，以便比較服務前後和評估是否納入備份計畫。 未列入檢討會議。決議：修訂服務導入流程。 結語 其實最大的問題會議上沒有討論到，實際導入時間從計畫到完成耗時2.5個月，規劃1個月、環境建置1個月、實際執行導入和宣導期0.5個月。規劃的1個月時間如果是非常急迫的狀況，有必要縮短。這此主要是規劃期間維運工單有許多急迫性問題，一直延宕，另外環境建置的1個月也是個問題，因為第一次架設會有學習成本，導致這一個月難以縮短，未來如果有急迫性任務應該要考慮找熟悉的人來處理（不過熟悉新系統的人是否熟悉目前架構就是另一個議題了，說不定有配合方式可以運作）。 另外一點是最早決定要導入的原因其實沒有100%解決問題，像是兩個資安因素，都是共用帳號的問題，但是最後還是沒有完全只有一人使用一組帳號，其實我在想就風險管理上，如果真的把服務帳號只給一個人，如果權限擁有者出事或是請長假的時候到底該怎麼辦？我的理解上資訊安全管理系統很重要的是究責和可溯性，如果以共同承擔風險的方式是否能夠避免這件事？ 不過實際上已經達成「 系統應盡量避免共用帳號」、「 應確認所管理之系統帳號皆為合法授權者」和「查詢不易」等三個問題點，我覺得這次導入是成功的～
《獨角獸專案：看IT部門如何引領百年企業振衰起敝，重返榮耀》快速筆記
本書是《鳳凰專案》的姊妹作，視角從管理者轉換到一名資深工程師。我很喜歡這本書不是單純的只講轉型方法，而是廣闊的討論到實際轉型過程中會遭遇到的政治紛爭以及利益衝突，雖然最後都順利解決的，但是現實往往沒那麼簡單，不過對於起步來說，已經給予了足夠的認知。 一、五大理念 1. 區域性和簡潔性（Locality and Simplicity）2. 專注, 流暢和快樂（Focus, Flow and Joy）3. 持續改善日常工作（Improvement of Daily Work）4. 心理上的安全感（Psychological Safety）5. 以顧客為中心（Customer Focus） 書中透過五大理念來實踐日常的工作和轉型的方法，我目前推測應該是作者自己所整理出來的幾個「心法」，我會說「心法」是因為每個人應該都有一套自己的道德觀和執行準則，這些東西很難變成一套完整的理論或是學說，但是有一定的參考價值，以及在多數狀況下的決策會很有幫助。 像是以單一程式工作任務來說，保持區域性和簡潔性可以形容成低耦合（Coupling）、高內聚（Cohesion）的程式設計原則。用在工作流程上來說，如果我們能夠確保工作流程上，多數相依工作都有一套穩定的價值流和簡潔的交付方式，能夠更快速的產生迭代，製造產出。 二、三層面理論 這個理論最早是Everett Rogers在1961年時提出的創新擴散理論（Diffusion of Innovation Theory），後來經由傑弗瑞‧摩爾（Geoffrey A.Moore）所寫的《跨越鴻溝》（Crossing the Chasm）再次拓展說明。 第一層面：公司現有的核心業務。 第二層面：新興業務。 第三層面：快速學習和廣泛探索商機。 公司現有賺錢的業務是屬於第一層面。而所有處於第一層面的業務，都是先透過第三層面的探索和進行快速篩選，而進到第二層面。再透過將第二層面的新興業務加以規模化、標準化，而成為第一層面的核心業務。 三、區分核心業務（Core Business）和脈絡業務（Context Business） 核心業務 （Core Business） 是和公司營運有極大相關性的業務內容，通常指的是主力營運項目。 脈絡業務 （Context Business） 指的是本身並不會影響公司營收能力的營運項目。 書中後期透過區分核心業務和脈絡業務，進而將脈絡業務透過一系列的評估手段將之外包出去，讓公司專注在核心業務的發展上。 四、函式語言程式設計 五、沃德利地圖（Wardley Mapping） 這是一套用於繪製出整體系統價值流概念的一個圖像化方法。
《鳳凰專案：看IT部門如何讓公司從谷底翻身的傳奇故事》快速筆記
本書透過一則新上任的IT經理所帶領的IT維運部門故事來闡述一些開發維運（DevOps）的方法論，在提出方法的同時，輔以案例的說明讓這本書不淪於一本純技術手冊。在故事中的主角遇到各個難題的時候，還有一位導師型的角色在過程中一直給予建議，開頭這名導師只是單純股東會候選人，但在結尾公司轉型完成之後，他放棄加入股東會以避免可能遇到的內線交易問題，改成以投資人的方式加入這場轉型，讓這本書的層次從公司營運，提升到了對金融市場的理解。 一、IT維運的四類工作 1. 業務專案：業務部門或是客戶對於IT的需求。 2. 內部專案：內部系統提出的需求。 3. 變更：因為優先度調整導致的工作變更。 4. 計畫外的工作：緊急修復之類本來沒有預期的工作。 如果沒有辦法辨別總共有幾類的工作，將無法對各工作類型做有效的安排。業務專案和內部專案兩者的本質類似，不過需求方不同，所能夠達到的績效也不同。變更任務對工程師（RD、PG）來說所花的時間可能是切換任務的時間，對專案經理（PM）可能是進行專案變更程序。計畫外的工作則是最影響IT維運的，很容易直接切進來打亂前面幾項所有工作，導致業務延後或是花時間在專案變更程序。 二、三步工作法 1. 第一步工作法：建立工作流，從開發到IT維運，最後再到客戶手上。 2. 第二步工作法：改善工作流。 3. 第三步工作法：建立相關文化。 這三步工作法其實和戴明循環（Plan-Do-Check-Action, PDCA）差異也不會太大，簡單來說就是透過第一步的建立工作流，對應到戴明循環的計畫（Plan）和執行（Do），第二步在做的就是查核（Check）和行動（Action），最後多了第三步建立這一個文化，是為了確保這個工作流不會消失。如果導入一套系統只用了一次或是只持續一年，那導入當然不算成功。 三、約束理論(Theory of Constraints, TOC) 1. 找出系統中存在哪些約束 2. 尋找突破這些約束的方法 3. 使企業的相關活動符合突破約束的方法 4. 持續2. 嘗試別的約束突破方法 5. 持續1. 找出其他的約束 四、開發維運（DevOps） 這本書的本質就是在講開發維運的轉型故事，不過捨棄了很多對於理論說明，就用了一則故事來說明如何一個步驟一個步驟將本來混亂的狀況轉變成有理論依據支撐且執行的作業流程。
以思科技新網站上線
以思科技有限公司，於2019年1月以Apollosome工作室之名義成立，隨著業務需求擴增，於2019年6月正式成立。 隨後為因應近來強化學術研究成果產業化之目的，進駐國立中正大學創新創業基地，以舉用新興技術人才，推動其銜接產業需求為目的，開拓嘉義辦公室。 2020年12月，有感於學術社群溝通平台之必要，開發「學術網站管理系統2.0」，便利國立中央大學、國立中正大學之行政上、教育上互動交流。 適逢公司建立兩週年，決以更效率更具安全性之面貌回應委託需求，不僅完善內部管理標準作業程序，導入資訊安全管理系統（ISMS），更重新整建網站內容及頁面，以期符合每位需求者之期待。