ENGINEERING
技術與工程作法
本頁說明我們如何讓系統穩定運作。內容刻意不堆疊技術名詞：需要判斷的是這些作法解決什麼問題，而不是使用了哪些工具。
INTEGRATION
系統整合：讓新舊系統之間資料相通
多數企業面臨的問題不是沒有系統，而是系統之間不相通。新建置的系統必須能與既有系統銜接，才不會再增加一個需要人工搬運資料的介面。
- 可介接的對象
- 金流、物流、政府機關申報平台、既有 ERP 與第三方 SaaS。只要對方提供 API 或能匯出資料，即可介接。
- 完全封閉的舊系統
- 即使沒有 API 仍有銜接方式。可採檔案交換或定期轉檔處理，不需為了單一新功能重建整套系統。
- 設備端的資料回傳
- 生產設備、感測器與量測儀器的狀態可即時回傳至系統，支援遠端監控與自動告警，取代人工抄表與定時巡檢。
- 一份資料、多個入口
- 官網、後台、App 與 LINE 共用同一份會員與訂單資料。客戶由哪個入口進入都對應同一筆紀錄，無須分別維護。
相關服務
客製化系統開發SECURITY
資安：明確界定誰能看到什麼
內部系統的風險多半不在外部入侵，而在權限界線不清。資安的第一步是界定權限，而不是先採購設備。
- 依部門與職務控管權限
- 系統設計階段即明確定義誰看得到哪些資料、能執行哪些動作。薪資、成本、客戶名單這類敏感資料，不會因為共用同一套系統而全體可見。
- 網路層的防護
- 防火牆規則、對外連線管理與辦公室網路架構一併規劃，除了維持系統穩定，也避免防護從內部網路被繞過。
- 最小必要存取與紀錄
- 我們維護時僅在必要範圍內存取資料，並保留查詢紀錄。AI 應用亦適用同一原則：限定可存取的資料範圍，查詢內容可供稽核。
- 表單與帳號的防濫用
- 對外表單以送出頻率限制與隱藏欄位阻擋自動程式，不採用需要辨識圖片的驗證碼——阻擋自動程式不應以增加真人的操作負擔為代價。
BACKUP & RECOVERY
備份與還原：關鍵在於能否確實復原
有備份不等於能夠復原。不少企業是在需要還原的當下，才發現備份檔案早已損毀，或無人熟悉還原程序。
- 定期備份，並實際演練還原
- 除排定備份外，另實際執行一次還原流程，確認資料可完整取回，且有人員熟悉操作程序。
- 架構選擇的依據
- 我們以四個問題決定架構：資料一旦遺失需回復到多久以前、尖峰時段有多少人同時使用、法規是否限定資料存放位置、未來三年的資料量會成長到什麼規模。四個答案齊備之後，架構通常只剩一個合理選項。
- 備份頻率與保留份數
- 備份頻率與保留份數依資料異動量與可承受的回復範圍規劃，是否採異地備份則視資料的重要性與法規要求評估，並於交付文件中載明。
- 故障後的復原目標
- 還原目標時間與可接受的資料遺失範圍，於規劃階段依系統停機造成的實際影響一併訂定，並以還原演練驗證是否達得到。
相關服務
企業網路規劃MAINTAINABILITY
可維護性：讓系統長期仍改得動
系統真正的成本不在建置完成的當下，而在往後每一次調整的時候。無法調整的系統，最終只能整套重建。
- 先確認畫面與規則再開發
- 將流程具體化為實際的畫面與規則，經你確認後才進入開發。認知落差在設計階段修正的成本最低，寫成程式後才發現則代價最高。
- 分階段交付
- 優先將影響最大的環節上線，使效益提早顯現，其餘功能再分階段迭代。每個階段都交付可實際操作的成果。
- 同一團隊負責到底
- 自諮詢至上線後維護皆不更換團隊。新增一個欄位或調整一段流程時，不需另有人員重新理解你的系統。
- 功能可隨業務擴充
- 客製化系統一次建置、長期使用，功能可隨業務持續擴充，不受套裝軟體既定邏輯的限制而只能回覆「做不到」。
HOW WE DECIDE
我們的判斷原則
同一項需求可以有多種作法。以下是我們判斷的原則，多數情況下能降低你的整體支出。
- 既有設備優先沿用
- 先盤點現有設備的規格與狀態，僅在效能不足、無法擴充或有安全疑慮時建議汰換，並附上理由與預估費用，不為了汰換而汰換。
- 不預設一律開發 App
- 使用頻率低的預約與查詢，LINE LIFF 免下載、免註冊，開發與推廣成本均低於 App。確有推播或裝置功能需求時，才建議開發原生 App。
- AI 的回答範圍受限
- 答案來源限定在你提供的知識庫，查無資料時即回覆「不確定」並轉由真人接手。寧可回覆不確定，也不讓系統對客戶提供未經確認的資訊。
- 不為了雲端而上雲端
- 雲端、自有主機與混合架構的成本與風險會逐項列出後共同決定，而非預設每一套系統都應移轉上雲。