Benjamin
Benjamin

新人工程師,偶爾分享工作心得(預計?

工作隨筆-緊急上線

星期三剛上班沒多久,收到主管傳過來的訊息,內容是線上服務主機的錯誤訊息。

為了維護、管理成本和穩定性等考量,現在很多公司都會使用Amazon的AWS服務,像是雲端伺服器、雲端資料庫之類的東西,我們公司也不例外。

登入帳號之後可以看到機器運作的記錄,包含程式執行錯誤時的例外資訊,用來檢查出錯的原因。而主管根據例外訊息紀錄的出錯部分,分配給負責開發這部分的工程師進行修正。


這次碰到的是程式開發時沒有檢查完整,使用了錯誤的資料來源當作參數導致的錯誤。

將出錯的功能簡單分成三部分,第一第二部分更新,第三部分刪除資料,發生的問題出在第二部分,導致第二部分的更新未完成,同時後面的第三部分也被中斷了,一套流程沒照預定計畫走完,這結果就是資料發生不同步,理應已刪除的資料仍然能搜尋得到,這是顯而易見的錯誤。


可以想見,這問題愈晚修正就可能有愈多用戶遭遇這種問題,所以正常的上線流程,如之前說過的D→S→P順序進行驗收顯然是來不及的,因此這種線上問題使用緊急上線流程,儘早修正問題後更新線上。

開發完成後,首先把本機開發的程式合併到D環境,確認問題解決之後,再從本機合併到P環境,即線上。
這種做法的目的是確保對線上的修改就只針對發生錯誤的部分程式而已,不會進一步產生其他問題,或者是與其他服務產生版本衝突,例如後端和前端溝通時的資料格式,如果進行大改版一定是兩邊配合著一起驗收,才可能正常運作。

確保用戶使用的程式穩定,這就是分層驗收最重要的目的。


如前面說的,第二部分執行中斷導致第三部分未能正常刪除資料,這種問題也是必須排除的。

但是線上就是線上,不允許開發人員直接對資料庫進行讀寫,為了把資料刪除,我必須先在系統寫一張資料異動單留下紀錄,關於改動內容、改動資料的語法、改動的原因等等,然後寫好刪除資料的腳本供主管執行,再由主管回覆刪除是成功或失敗,以及其回傳的訊息。

幾個小時就這麼過去了。


可以的話真想盡量保持細心減少錯誤,修正過程必要的流程有點繁瑣,又進一步延後了後續預計要進行的工作,只是為了讓程式回到「正常狀態」,而沒有產出。

CC BY-NC-ND 2.0 版权声明

喜欢我的文章吗?
别忘了给点支持与赞赏,让我知道创作的路上有你陪伴。

加载中…
加载中…

发布评论