Please enable JavaScript.
Coggle requires JavaScript to display documents.
CTO職責 我想做的事 (技術 (技術發展 (在不影響穩定維運情況下，最適化完成效率的方式 (發展目標/方向明確 (可衡量的成長, 可預期的),…
CTO職責
我想做的事
技術
現有技術升級
系統服務升級
網路服務升級
軟體服務升級
目標
短期
現有問題處理
效能瓶頸
測試準則
測試涵蓋率
單元測試
問題記錄
中期
使用 開源 快速技術導入
監控可量化
API運行
長期
知名
南部知名
品牌
價值
自有開源產品
可量化衡量的
技術發展
(類)微服務
自動化
標準化
範本
規格化
產出
技術發展路線圖
技術白皮書
公司
產品
團隊
行動APP優化
在不影響穩定維運情況下，最適化完成效率的方式
提升人員能力
產品認同感
團隊向心力
發展目標/方向明確
可衡量的成長
可預期的
雲產品應用
更多的外部產品介接
開發者中心
監控儀表版
運維狀態
開發文件
API文件
設計文件
線上發佈/更新/通告
文化
共享
各團隊技術研討會
產品上線前發表會
教育訓練
自主
自動
風險管理
數值化
監控化
規則化
外界技術發展
定期介紹
下一代產品
研究如何運用新的技術改進
創造新的產品及服務
參加研討會
參與研討會
策劃技術沙龍
建設技術網站，發表技術文章
軟體架構
軟體平台
安全
資料科學
文化管理
看得見的價值
透明化的road map
加強溝通協作
對下
對上
公司技術白皮書
同步技術發展規劃/時間
有效率的溝通
小專案制
透明的進度及排程
明確的優先權
專案進行回饋
必要的專案文件
資源利用的最佳化
提案
代理人/後備人員
定期/不定期分享
新手訓練營
最佳實踐
精兵政策
維運
穩定
負載均衡
快速 Failure Over
風險監控
數值化
監控儀表版
通報/通知
告警
線上更新
每次線上更新或停機皆需事先通知
至少配置二台以上服務，更新不影響線上
快速回應
客服系統
專家分析查詢
常見問題整理
提前示警
歸因分析
需求管理
業主需求
SuperKF
操作手冊/說明
需求回饋
用戶需求
維運需求
通知/告警
運行狀況
流量
API
Web
JVM
數值化
運維手冊
技術需求
自助化
自部署
ELK
自已做的程式，自己更知道問題是什麼
系統運行狀態、網路運行狀態
輔助營運
數據分析
用戶體驗優化
自動化
CI/CD
Docker
K8S
開發整合系統及網路服務的更佳做法
Infrastructure as Code
Ansible
故障自愈
自動擴容
基礎建設強化
基礎應用服務
Gateway
Consul
Shell
Cacti
流量分析
Serverless
基礎硬體服務
第二機房
硬體採購
基礎安全服務
工具
流程
組織結構
IT配置管理
環境配置標準化
服務器設備配置標準化
網路設備配置標準化
儲存設備配置標準化
OS配置標準化
中間件配置標準化
資料庫配置標準化
應用服務配置標準化
rProxy
Web
APP
Application
用戶線路配置準準化
業主線路配置標準化
IT基礎架構組件標準化
電源管理標準化
物理服務器管理標準化
交換器路由標準化
網路安全設備管理標準化
負載均衡設備管理標準化
儲存設備管理標準化
系統管理標準化
虛擬機/容器管理標準化
基礎應用管理標準化
備份與怖復標準化
危機及演習標準化
IT應用服務組件標準化
Oracle管理標準化
MySQL管理標準化
MarialDB管理標準化
Tomcat管理標準化
Spring Boot Server管理標準化
Nginx/Proxy管理標準化
Memcached管理標準化
MQ管理標準化
IT運維流程標準化
資源申請流程
資源上架流程
資源安裝流程
資源發佈流程
資源配置流程
資源配置流程
資源變更流程
資源到期下架流程
資源備份/恢復流程
資源災難切換流程
運維事件/問題處理流程
統一監控標準化
主機/虛擬器/容器監控標準化
資料庫監控標準化
儲存監控標準化
I/O
應用
中間件監控標準化
網路安全監控標準化
基礎應用監控標準化
網路監控標準化
備份與容災監控標準化
電源監控標準化
APM與業務功能監測標準化
目標
適當的 publish data 加強與客戶的連結
開發與維運一體 (DevOps)
維運了解開發流程
開發了解維運流程
優化並結合兩者流程
先自動化再標準化，邊標準化邊自動化，即自動化，又標準化。
如果現行操作能滿足應用業務的支撐，那就開始自動化運維平台、自動化運維工具和自動化運維流程。
最佳方法就是有範本可以看、可以模仿
監控
在儘量不影響效能情況下，監控一切能監控的
降低重覆操作，故障排查工作
相同問題/做法重覆三次，應該就要考量自動化
錢
賺錢
收入來源
長短期收益
省錢
平衡發展與成本
找錢
借用外部資源
賠錢
評估決策風險
分錢
內外部利益分配
投錢
獲取外部發展機會
開發
技能提升
訓練
自主性
掌握度
使命感
模板
自我學習
案例分享
品質
測試
規範
Web API/Rest API
XX開發規範
OO產品開發規格
必要的分析文件
必要的流程
code review
unit test
code analysis
git flow
工具
check style
PMD
Code review
不能錯
提升協作效率
做對的事
需求源頭管理
開發分析規格
把事做對
想得跟做的一樣
範本
開發流程
開發基礎建設
規範
前端
UI
APP 開發規範
WebUI 規範
模組
後端
Rest API
Mode API
架構設計
基礎建設
Web API/ Rest api
分散的
無狀態的
可自我註冊的
安全的
統一的規範
認證中心
API說明
軟體基礎服務
Git, Gradle, Nexus
開發架構
前端
Angular
前端 call trace
crash report
中介端
後端
Service
Control
Rest API
Web API
Model
DAO
call trace
使用人數
分析
成本的
人力的
時間的
品質的
公司OKR
技術面
團隊
打造高效率的技術團隊
技術解決方案提供
解決現有問題
專注/不重工
買錯比買貴還貴
L2機房規劃與建置
目標
方法
前後端實體分離
自動化
SWOT
Strength - 利用、強化、提升
累積的經驗
豐富的特定產品開發、維運一條龍經驗
系統架設/監控流程/規劃能力/防DDOS
有足夠能力進行技術研發、產品開發及維運工具研發
Weakness - 監視
開發
人員素質不一，缺乏有效經驗傳承
技術
缺少code review 規範、自動檢查 的工具或方法論
產品
缺少量化指標，應用服務的風險監控難以完成
Opportunity - 改進、提升
愈多廠商投入，產業體系愈穩定，有自有產品及研發能力者，更有機會拓大規模，強強合作
DevOps愈來愈多應用、開源及研討會
雲端化技術愈趨成熟，可降低維運風險，提升服務品質
Threat - 改進、消除
只有單一定點機房，若有不可預期事件發生，將造成營運停擺，用戶流失
傳統開發及設備單一應用，難以擴容，無法因應規模增縮而快速調整
行動用戶愈來愈多，公司產品不足以吸引行動用戶
雲端機房愈趨便利及成本降低，競爭者進入門檻大幅降低，公司仍以實體機房為主
考慮
[競爭分析、短中長營運規畫]->SWOT->[方針、策略]->行動方案->關鍵績效指標->指標定義->績效管理與發展
為什麼要做、如何做、該不該做，自我覺察
差異化、獨特性、集中目標、獲得客戶認同
策略
目標
為達成特定目標，所擬訂與規劃執行之方針與行動方案
思考、分析、取捨、規劃
事業藍圖
BGG矩陣
金牛/明星/狗/幼童
Porter
經營效能
包含效率但不限於效率
獨特競爭力
取捨(trade-off)
設定限制(可為與不可為)
商業活動
自動化
自助化
基礎服務
APP優先
2019T3OKR
提升開發產出品質
提高單元測試覆蓋率
開發規範與上線計畫
找出至少3項以上可自動化流程及改善
提出並完成2項自助化服務給其他團隊使用
建構並維護產品知識庫
加強團隊協作及技術分享
跨團隊進行至少三場維運經驗分享
應用至少3件可協助改善開發效率的工具
發展至少2項團隊 CI/CD 服務
加強應用服務行動化
完成至少3項行動服務優化
新建至少3項行動產品或服務
達成至少3項DevOps質量監控項目及指標
提升自動化服務
提升自助化服務
風險預防與監控告警
故障演練3次
找出可提升服務可用性及其指標至少3個
保證故障的快速定位級解決能在0.5小時內完成
分析服務或遊戲上線回饋及改善
完善基礎建設以穩定服務及系統品質
於11月底前完成 Web/Rest API 服務與重構
於11月底前完成第二機房第一期建置
於10月底完成前後端分離設計與重構
找出至少3項線上系統穩定性相關指標與改善
降低未知風險帶來的服務停機或怠機影響，要能於4小時內回復