嗯。
對。
還是要看條件啦！畢竟還有硬體、軟體那一些。
對，但是要考量到DB的，台北跟台中的資料是否要一致，即使一致還是什麼時候一致，這個需要考量的。
對，AS還要再弄一套，而且在DB層怎麼樣把資料sync一致，也是一個issue。
是。
對，假設真的是2、3、4都掛，因為1還有承受量，如果少量的話，就……
應該說這張圖比如以台北的整個環境。
對，就是會建造一個能夠（被打斷）……
（簡報第27頁）接著是我們建議的架構，基本上不會差太多，只是說我們會切三層式的架構，每一個階層間都有firewall，OID會變為Cluster，並且使用相同的DB，以及我們的安控程式會讓管理者有單一的管理界面，報告完畢。
（簡報第26頁）我們會建議我們的做法，以系統架構來講，改為三層架構，能夠提升安全性。OID設為Cluster，並且與OAM使用相同的RAC DB就可以了。接著是安控系統布署的AP Domain都設為Cluster，然後能夠統一管理。OS改為Linux，並且統一安裝帳號，以及建立異地備援的機制。
（簡報第23頁至第24頁）接著是OHS及OAM，我們有去調整CPU、Weblogic的參數及OAM一些軟體裡面的設定值。我們也有去調整LDAP使用多少的CPU。
（簡報第22頁）這裡有列出一些參數的調整列表，第一個Bad Request，當初使用者有反應使用者用一段時間之後會有Bad Request出現，這個時候我們調整OHS，讓HTTP Header能夠變得更強，預設是2048及4096，我們多加一個「0」，讓它多了10倍。
（簡報第17頁第21頁）這幾頁是壓測軟體所產生出來的報表，我們不特別說明。
接著是我們又進行了「編號4」、「編號5」另外的一些步驟調整，然後我們再測，「編號4」、「編號5」的話會比較偏向於真的有按照這一個測試腳本來測，「編號1」、「編號2」、「編號3」主要是以壓測人次來打，「編號4」、「編號5」之後才會按照上面的壓測腳本來做，而且是「17人/秒」，那時測的最大值是「17人/秒」，調整前「17人/秒」的登入動作可能從1秒鐘至2分鐘都有可能，並且錯誤的次數很多，可以看到總人次因為有錯誤，而且回覆的時間也慢，所以總人次只有7,000多，但是調整之後的相同條件下，response就回覆到1秒，並且總人次變成1萬6,000人。
所以第三次我們調整之後，相同的條件是「20人/5秒」，然後接著總人次是2,000人，這次我們在測的時候，時間已經大幅縮短，登入時間變成1至3秒，並且無誤。
所以那時候就懷疑OAM這一套系統在當初的狀況來講會有兩個瓶頸，一個是每秒多少人登入是一個瓶頸，一個是總登入人次也會是問題產生的可能點。
下表主要會分為兩個大章節，可以看到秒跟人數會有落差，我在測試初期可能不會以那麼大量的人數來打，所以我一開始在測的時候，是5秒鐘20個人，我們先看1至3這邊，比如第一個項目是5秒鐘的20個人時，我們打到1,200人次，等於我壓測幾次，那個時間是1秒鐘到70秒，變成沒有錯誤，後來在相同的條件下是5秒20人，但是我的人次打到2,000的時候，其實就會有一些錯誤產生。
（簡報第16頁）OAM才是比較主要的部分，我們的測試腳本主要分為兩個項目，第一個項目是2,000人於5分鐘之內，全部登入一次完畢，所以平均下來可能是7人/秒，只是第一個腳本是2,000人登完就不再做事，然後真的有在做事情的是後面另外一個步驟，也就是在2,000人登完之後，再繼續以500人的30秒登入完畢，並且每人重複30秒，30秒再重複登入一次，主要是這一個作業。
（簡報第14頁至第15頁）這兩張表則是我壓測軟體所跑出來的報表，有興趣可以看一下。
所以這一個OHS測完之後，目前我設定值就先停到這邊，繼續測下一個步驟，有包含OAM的地方。
對，他要用MPM_winnt，所以我們後來也調整了。下表可以看到，假設我們設woker，即便調到8,000，測試期間也不會改變，是1至60秒（參照簡報是記載67秒），但是我們一調了winnt之後，我們調到350，當然可以再往上調，但是測試的結果，基本上以這一個條件下，response就是1、2秒的時間就已經達成。
首先，我們測試的系統是OHS，並且我那時模擬的是，每秒三百人開啟的登入畫面，我不做登入，只是一直打，然後持續五分鐘。在測試初期，因為我們的經驗比較多是在Linux上，所以我們一開始初期設定的參數調整，其實是屬於MPM_worker的參數設定，但後來我們測了之後，一直覺得為什麼沒有用，所以我們後來又找了相關的資料，才發現到其實在……
（簡報第13頁）我等一下會首先說明使用者流程，也就是使用者看到的登入畫面，因為這邊只包含到使用者連到網路，因此包含的項目只有網路、OHS及安控的程式，第一個步驟不會包含OAM，所以我分為兩個步驟來測。
我們說明一下我們使用的壓測軟體，使用的壓測軟體是OATS（Oracle Application Testing Suite），並且我們的壓測時間是從10月12日開始，因為10月12日之前，大大小小有很多颱風，所以剛好沒有辦法在那邊測，所以幾乎是從颱風季過了之後再開始測，並且一直測到11月29日，差不多這個時間。
（簡報第12頁）我們說明一下壓測的歷程，我們負責的部分比較單純一點，其實只有使用者看到的首頁、登入，及登入到的系統主頁，我們沒有包含後面應用程式的布署。所以就我壓測的時候，我分為兩個步驟：一個是使用者看到登入畫面，可能什麼事都不用做；接著是使用者真的輸入帳號密碼之後，最原始六快磚的畫面。主要的壓測就是這兩個大項目，因為這兩塊基本上就可以包含到所有的項目。
第三，系統效能的參數，之前都是預設值，後來做了很多次的壓測，去調整了系統參數，也增進了系統效能。
第二，消防署跟我們反映使用者在使用上不定時出現Bad Request的問題，我們也是找了一些資料，然後去做OHS的參數修改，從去年的11月修改之後，目前沒有這一個問題；
第一，OID原本有預設密碼到期時間，但是當初可能交接的時候沒有很清楚交代，所以有遇到一個密碼到期時的問題，忽然很多人遇到密碼到期，所以我們後來調了，讓它的到期時間修改；
（簡報第11頁）接著是維護期間的時間整理，主要有三點：
第五，主機OS均為Windows。就我們的經驗來講，還是建議以Linux為base的OS。
第四，OS使用的帳號不統一；
第三，四個AP Domain各自獨立，因無Cluster，所以之後的管理可能要四次，如果有做Cluster的話，我們可以由統一的單位去管理；
第二，兩台OID各自獨立安裝，並在本機安裝單獨DB；
第一，所有主機皆在同一網段，有安全疑慮；
（簡報第10頁）我們接手之後，我們評估後提出以下幾點，就我們來看是比較不建議的地方：
（簡報第9頁）接著說明這個是這四個月來營運狀況的說明。
實際上登入的流程之中是OAM在做，所以OAM這邊規劃兩台，並且有做Cluster。因為帳號的來源是OID，所以也有做兩台，只是獨立的兩台去做LDAP，並且有DB。這邊主要系統的DB是Oracle DB。
使用者在登入的時候，輸入網址之後，其實會打到四台，會經由load balancer去sharing loading，打到四台Web Server，並且Web Server裡面都會各自有一個OHS Server，以及Weblogic Server。
（簡報第8頁）這個是現行的系統架構，可以看到右上角的部分，會有OHS、WG，這個是說明這一張圖裡面縮寫代表什麼意思，像「OHS」指的是Oracle HTTP Server，主要是Web Server，是以Apache當作底層的架構。接著「WG」是「WebGate」，作為single sign on攔截session的軟體，作為一個plugin安裝在OHS上去。接著是「Weblogic」是AP Server，就是各應用系統運作的平台。接著是「OAM（Oracle Access Manager）」，Oracle推出套裝軟體，作登入的認證跟授權。接著是「OID」是一個LDAP的Server。接著是「Oracle DB」。
（簡報第7頁）這是應變中心的主畫面，各使用者應其需求而點到不同的項目。（上述）是整個負責登入的流程。
登入有兩種方式，第一種是左邊的，用「我的E政府」帳號登入，登入就會連結到E政府；另外一邊是右邊的「機關帳號登入」，正常來講我們都是比較負責「機關帳號登入」，因為帳號來源是我們自己的OID LDAP，使用者在輸入帳號密碼之後就會到後端的LDAP認證，確認可以登入之後就跳到下一頁。
（簡報第5頁）因為時間只有四個月，當時做的方式主要是偏向於對於做系統的調校，程式的部分我們沒有特別動它。這個（投影畫面）是系統畫面，這裡所說的「系統」是消防署防救災入口網站，Url是「Portal.emic.gov.tw」，只要一打這個網址之後，就會跳到下面的首頁，這個是應變中心登入的。
（簡報第4頁）範疇：主要是在維護安控系統的穩定性，並且在災害應變開設期間，我們人員會進駐，以確保不會中斷，使系統都能使用。並且，在專案期間會進行系統優化調整，讓我們的效能能夠儘量達到最好。時程：其實是從去年9月16日至去年12月31日，所以將近有四個月的時間。
（簡報第3頁）首先先看到承攬範圍的說明，我們會說明到專案範疇及系統的現行畫面，讓大家瞭解一下，接著是對於現行的系統架構，我們也有畫架構圖，以便讓大家瞭解。
政委好，首先是（簡報第2頁）Agenda，我這邊主要會有三個範圍：第一個，先說明承攬範圍；第二個，承攬狀況之後狀況說明；第三個，未來建議及做法。
