# How FinTech Embrace Change Management - smalltown（蔡宗城）│AMIS

{%hackmd s5C2l4iTQ7yK8Pg4ASCGvw %}

> 請從這裡開始共筆

你怎麼在你的production環境下做變更？
有經過approve才能做嗎？

#### No one knows ____ Change(s) in the Production
- Why
- What
- Who
- How
- When

## Change management
把production上要做的改變，標準化 => 降低風險

### Change types (ITIL)
- standard change: 低風險，跟著SOP
- emergency change: hotfix
- normal change: infrastructure, config

Non standard change 要提出 request for change (RFC)

#### 傳統的做法
Change Request Form(request for change, RFC)，把表單填好送出去，簽核
速度慢，新創公司還沒做出來就先掛了

#### 現代化公司，實際可能的作法
- 沒辦法(沒時間)自己做RFC ticket system
- 搭配chatbot
- 自動化給予權限的流程

#### Keep only necesary step in RFC flow
將影響降到最低

#### 有效性
用chatbot自動化。變更被提出來，還沒有被approve之前，是不可以做變更的
先將系統 lockup

#### 人的問題
持續溝通
先從簡單的做起
- 先從 chatbot 做紀錄，方便後續審核上 production 操作的必要性
- 從 chatbot note 中了解, production 上需要哪些操作 or 哪些 action 是可以避免/automation, 安排 backlog 去解決
- e.g.
- CD script broken
- CD pipeline not implemented
- 主管支持

## Implement

#### Analysis Changes in Production
分析出change的各種形式
- permission grant佔20%
- Production release佔70%
- others

所以首要先簡化production release

#### Define RFC Process
流程圖

### System design

#### 事前準備
- 定義出組織內每個人，在系統內是誰，要有統一且唯一的 UID
- RFC system，要把不同BU，不同team拆開來。否則表單填寫會很難選

#### Demo
* Notify the RFC result to Slack/Teams let members/ops team view the detail information easily

### Permission grant/revoke
- 啟用認證機制
- 帳號要先做好管理
- auditing log enable

#### Demo
- Automate the each workflow and show the detai status on teh RFC Slack channel
- Permission approval
- Permission grant
- Permission remove

### Production release
- 了解每個team的git flow，RFC的hook要插在哪個環節
- 定義RFC怎樣才可被approve => 使用 github action 的 status check 增加部署的信心
- code review
- RFC check
- testing
- code coverage

#### Demo

###### tags: `DevOpsDays Taipei 2021`