今天我要講一個SSO還是SOS的故事，那到底什麼是SSO與SOS的故事呢？不要問我其實我也不知道，但是你如果硬是要我說一個故事來唬爛你的話，那我可以告訴你這其實是一個關於為了維護世界和平，一個男人必需不停登入登出再登出登入，進了又出，出了又進的微美浪漫甜蜜又感人的帳號登入的故事。
OK，讓我們切入正題，因為只有五分鐘，我也就不廢話多說！其實從我去年被轉調到SSO以來，由於面對的是一個沒碰過的Linux陌生領域以及正要試著轉型成全TM唯一入口的SSO Service，所以在這過程中其實一直很不順，那所以才會有這種開玩笑的想法說這其實不是SSO，而是SOS.
但不管過程如何，我想我還是跟著這個SSO專案一起走過來了！對我而言其實最大的難點不在於對Linux的Operation的新接觸，而是整個做事文化與思維的改變，主要是因為SSO新團隊的工作文化必然不同於之前我待的Partner Integration，再者是對於SSO這麼複雜的Service，應用過去已知的做事方式會發現到總是無法招架應付，這之中挑戰甚劇，到現在我想還在不斷摸索與學習。
在這過程之中，當然也不是沒有收獲。SSO Domain Know how是一個，而Linux的操作跟一些測試技巧的使用都是我在參與SSO過程中學到的很基本但重要的技能，其實Linux真的常用的指令就都固定那幾個，你只是需要時間去熟悉並且試著找工具來增加工作效率而已，所以Linux Operation其實沒有很高深的學問在裡面。
而另一方面面對SAML與Memcache以及SSO裡面錯綜複雜的Configuration，在這之中我其實吃了不少苦頭！因為想要對SSO的運作過程做Trouble Shoot或細部了解，一些以前沒學過的測試基本功，必需要做得夠紮實跟徹底。不只如此，因為SSO本身又是高度依賴Browser的Cookie以及Web Session 機制的Service，所以對於SSO 的平常Operation而言，如何善用Browser工具以及Linux操作和SSO Know how來追蹤每一個Request以及問題，永遠是最首要的基本功。
但其實最困難的不是這些技術面上的成長，令人最頭痛的應該是SSO的平常Maintain跟管理，尤其現在SSO已經在AWS上，所以運作方式又比過去在DCS時代複雜許多。所以現在SSO正面臨管理方法上的挑戰，在這邊我有一些想法可以跟大家分享。
第一個是多環境又多機器下的維護管理怎麼做? 過去SSO其實並不是我們全Team機器最多的Service，但是SSO的Configuration絕對是我們全Team最複雜的。而相信有些人應該已經聽說過SSO現在正在做Two Factor，而為了Two Factor，新的設計架構將會使SSO在每個環境多出4台新機器，其中包含兩台Windows Server，這將使未來SSO機器數超過Liberal成為全Team第一。在這種情況下，我們應該提出主動式的做法，來管理這數量龐大的SSO機器，而我所謂的主動式做法其實就是制定一套新的Monitor機制，讓我們可以盡量避免自己介入去看每一台機器與跟他本身Service的狀態，讓機器與Service可以自己監視自己，再回頭來告訴我們他哪裡不對勁，所以叫作主動式Monitor管理。
第二是更靈活的自動化測試，雖然目前在Robot上的E2E測試已大大增加我們SSO測試效率，但是其中的穩定度以及測試時間仍有提升空間。在這邊我們還是需要將目前測試的穩定度進一步提升，然後實作能和自動部署整合的測試流程，所以在這邊除了要能夠自動Run E2E的測試以外，更要能達成多個Robot同時進行SSO單點測試，這樣才能完全發揮自動化測試的功能。
第三是建構雲端作業的新MindSet，因為我們已經在AWS上，既然是在AWS上，很多過往Local的做法或許必需進行調整，例如分析Log的方式，同時應該加入更加完整的安全性測試，Security Testing，雲端的世界太虛無飄渺，所以要建立新的MindSet其實並不容易，但總是要有個起頭，我們可以挑重要的開始做，一步一步建立新的MindSet，再不斷修正不足之處，這是很重要的策略！
以上是我為大家帶來的個人在SSO上的工作與想法的分享，謝謝！
2017年5月3日星期三2:44 AM
留言列表
