雲端重建一天衝刺，清單從41降到30
8月6日是雲端重建行動最忙碌的一天之一，忙到連磁碟空間都跟不上。當天靠著把已經確認沒用的暫存資料清乾淨，可用空間一度從不到1GiB回升到大約12GiB；但隨著白天陸續有十幾個網站同時在做全新建置與部署，空間又被吃掉，我們當天又反覆做了幾次同樣的暫存快取清理才撐過去。
雲端重建清單一天內從41站做到30站
延續8月5日開始的「零流失雲端重建」，8月6日一整天陸續把好幾個網站逐一從乾淨原始碼重建、驗證零流失後正式換版。清單原本掛著49個網站待處理，這天稍早還剩41個，到了下午做到35個，再到32個，晚上B 站上線後只剩30個。個別網站的重建結果也有具體數字可查：C 站重建後，官網6,474個網址逐一測過都正常，其中70個是刻意不讓搜尋引擎收錄的頁面；D 站則是431個網址全部測過都是200（正常）。
十幾個網站同時上新文章，審核擋下了好幾次
同一天，我們也替十幾個網站各自新增3篇回答讀者真實問題的文章，每篇都要經過一位沒有參與寫作的人重新審核才能上線。這個機制那天真的擋下了好幾次：E 站有一張顯示充電座滿格的情境圖，因為可能被誤讀成邊開車邊滑手機而打回重畫；F 站的新版本裡，一個找不到頁面時顯示的畫面跟正式網站現有的差了幾個位元組（612位元組對376位元組），被抓出來後改成完全一致才過關；G 站有一張計程車情境圖裡帶到地圖介面，審核不放心，重畫成完全沒有畫面、地圖或文字的版本。H 站、I 站等網站，則是被抓到候選版本裡的舊網頁（H 站276個、I 站51個）內容其實落後現網、一旦直接上線等於讓舊頁面被換回舊版本——其中I 站那批舊頁面連更新時間都被悄悄改到很久以前的日期。我們因此改成先原封不動複製現有正式網站，只在後面加上新文章，不去動任何舊頁面。
A 站上線，順便抓到一個計時側漏洞
當天稍晚，A 站作為第19個（全部86個網站裡）完成上線的網站，也走完同一套獨立審核流程。審核的人同時也順手檢查了當天新寫的一段內部服務驗證程式碼，抓到一個問題：程式在比對驗證字串時，只要前面幾個字元不對就會提早結束比對，理論上有心人可以反覆嘗試、透過量測程式回應的快慢，一點一滴猜出正確答案。這個問題在上線前就改成不管前面對不對、都跑完整段比對，再重新測過一次才放行。
這天另外還發生幾次自動化工具在沒有明確要求下，額外建立了用不到的雲端專案（一次是幫某個網站建立部署工具時多出來的專案、一次是另一個站的測試環境），我們發現後都先記錄下來，等確認清楚了才個別刪除，沒有自己直接動手清掉。地址與公司這兩份共用資料，也在這天完成搬到雲端物件儲存的最後一哩——地址資料16秒就打包完成、產出12個檔案，公司資料則花了2分53秒、產出1,365個檔案，往後其他網站要用到這兩份資料，直接讀雲端版本，不用再各自留一份龐大的本機資料庫。
這天其他出錯的地方
- 其中一個站的候選版本一度把130筆正式網址的canonical網址誤換成另一個別名網域，加上其中一篇文章的非實測揭露文字寫得不夠清楚，被抓到後改回原網域、補齊揭露文字才過關。
- 另一個站當天稍早已經公開的三篇新文章，被查核抓到缺少非親訪的揭露說明與圖片來源紀錄，先判定不算數，補齊後才正式列入完成站數。
- 設定一個只保留程式碼、不含資料的本機工作環境時，一度不小心把限定範圍套用到上層共用目錄，發現後立刻關閉還原，沒有造成任何檔案遺失。
- 把地址與公司資料搬到雲端物件儲存時，第一次嘗試因為存取金鑰還沒設定好而失敗，補上設定後才重新跑成功。