今天一大早就趕過去，平時九點才到上班地方，今天剛八點就到上班地，趕緊開電腦把即將驗收的各個系統看了一遍，看看各個服務是否正常。
大家還是按照之前驗收的標准模式進行准備，先演講PPT，后講系統走流程，然后等專家就此發問。專家組如期到達會議室，坐下也沒那么多余的話題，直接上來就讓安排那個項目先來，客戶單位安排我方平台先來。作為技術人員心想出面的機會應該比較少吧，只要做好演示期間各系統保障工作，應對下專家組的簡單提問應該問題不大。
出乎大家意料之外，專家組牽頭的人員直接拋開繁復的系統及驗收文檔，從軟件系統工程角度來進行發問。
讓我方弄一個系統整體架構圖給他看（估計各位看官覺得這不很正常么），可萬沒想到這塊竟然出問題了，沒有，找不到，演講者也是一臉蒙圈滴看看我，看看經理，這下搞的有點大啊，好吧，這東西沒有，那就繼續。《系統整體設計方案》應該有吧，趕緊從N多檔案資料里面找出這本子遞給專家。
專家先翻看到系統概要設計，提問開始，密保等級做了沒？定到幾級？第三方測評做了沒？有測評報告沒？這塊回復甲方幫我方回復了，感覺上這塊應該是過去了。接下來又問檔案材料本子上的內容，文檔格式是否按照國標進行的？是否有監理出具的意見書？監理是否認真核對過？這塊工作由合作方經理回復，明確是按照國標進行的編寫的，但是監理這塊沒有認真核對並且出具相應的意見書，這塊是需要進行補充的。
以下幾點感覺第一次提出的如此清晰：
1、邊界管理，如何管理的；
2、WebService接口、數據交換如何管理，接口日志、交換日志、用戶操作日志、訪問控制、關鍵敏感數據的處理；
3、數據交換平台的正規化，如何在頁面上創建新的交換任務，配置交換任務的SQL，而不是通過線下進行創建；
4、平台用戶操作記錄；
5、各個子系統采取的是單獨部署還是一個系統多個分模塊？
6、流程是否支持自定義；
7、軟件系統的架構是如何設計的；
8、系統安全、敏感數據如何保密、權限控制（當前人員只能看到自己處理過的）
整個過程完全被專家控制，說有的東西一定要拿出具體的功能給對方演示看，演示過程中還要針對細節問題進行深入的詢問。好幾次都被問的“熄火”了，都不知道如何回復了。比如：當問起系統架構設計相關問題的時候，一是之前就沒准備過這塊東西，二是我並沒有參與過這套系統設計，也是半路參與進來的，所以僅能說是三層架構，之后就不知道該說點啥了。再比如：查看日志的時候，給對方說的是有日志記錄，可是打開日志文件，卻什么內容也沒（相當衰）。
整個審核會議開完后，感覺壓力巨大，
1、感覺自己也很冤，系統上本來也是沒有用戶操作日志的，我沒有辦法給對方展示這塊內容，但是有點感覺就是我領導有點不相信，看他們也是急的給系統開發打電話咨詢；
2、半路接手的項目，從未考慮過系統整體架構這類東西，也或許公司也沒打算讓我了解這些，所以對這塊提問我也是愛莫能助啊，可是領導的言行讓我感覺貌似是我的錯，快兩年了怎么連這個也沒搞清楚。
3、沒好的語言表達能力，不知道如何從那樣的“殘局”中找到有利我方的信息，領導坐了一圈，也不敢輕易說，擔心自己說錯了。
哎，該扛的雷還得扛啊，三十多歲了，突然感覺自己白干了這么多年軟件，自己的領導又如何看自己呢，前途未卜啊。
話說回來，這次的驗收工作也算是讓自己看明白自己不足的地方，讓自己學習了很多東西：
1、系統運維或實施（說實話自己都不知道自己現在到底是干啥的），最好搞清楚系統的整體架構設計；
2、系統驗收的時候，相關准備材料都必須按照國標進行編寫；
3、比較重要的系統，日志記錄不僅要明細還要全面；詳細記錄用戶的每一步操作；
4、對外接口管理也一定要精確，比如：IP地址管理、訪問用戶管理、日志明細等；
5、數據交換平台，其一定要保持一定的完整性（交換日志、數據源、任務管理、任務日志）；
6、一定要做到心中有數，一定要把自己手頭上的事情搞清楚、明白。邊界在哪、接口、數據交換、數據庫、系統平台等等。
7、面對各種誤解，一定要及時與對方溝通，可能自己會說錯話，但是一定要鼓起勇氣說。