first commit

.gitignore

@@ -0,0 +1,24 @@
+# Build and Release Folders
+bin-debug/
+bin-release/
+[Oo]bj/
+[Bb]in/
+
+# Other files and folders
+.settings/
+
+.obsidian/
+node_modules/
+public/
+
+# Executables
+*.swf
+*.air
+*.ipa
+*.apk
+
+# Project files, i.e. `.project`, `.actionScriptProperties` and `.flexProperties`
+# should NOT be excluded as they contain compiler settings and other important
+# information for Eclipse / Flash Builder.
+
+*.mov

.vimrc

@@ -0,0 +1,279 @@
+"=============================================================================
+"     FileName: _vimrc
+"         Desc: _vimrc/_gvimrc for windows
+"       Author: Chen Gan
+"        Email: gavin.chan.hz@gmail.com
+"     HomePage: xxxx.xxx.net/gavin
+"      Version: 0.0.1
+"   LastChange: 2014-01-17 09:07:16
+"      History:
+"               add VAM (vim addon management) - 2014/1/11                                                                  "
+"=============================================================================
+
+"
+" echo "loading _vimrc ... "
+"
+
+source $VIMRUNTIME/vimrc_example.vim
+source $VIMRUNTIME/mswin.vim
+behave mswin
+"colorscheme zellner
+colorscheme desert
+
+"
+" <20><><EFBFBD>ı<EFBFBD><C4B1><EFBFBD>
+" ͬʱ֧<CAB1><D6A7>GBK<42><4B>UTF-8<><38><EFBFBD><EFBFBD>
+"
+set fileencodings=ucs-bom,utf-8,cp936
+set fileencoding=utf-8
+"set encoding=cp936 
+set encoding=utf-8
+
+"
+" font of display
+"
+set guifont=Lucida_Console:h15:cANSI
+
+"
+"
+" <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
+"
+winsize 1024 768
+"au GUIEnter * simalt ~x
+"colorscheme desert
+
+"
+"<22>Զ<EFBFBD><D4B6><EFBFBD><EFBFBD><EFBFBD>
+"
+set autoindent
+
+"
+"<22>м<EFBFBD><D0BC><EFBFBD>
+"
+set linespace=2
+
+"
+"<22><><EFBFBD><EFBFBD>tab<61>Ʊ<EFBFBD><C6B1><EFBFBD>Ϊ4<CEAA><34><EFBFBD>ո<EFBFBD>
+"
+set ts=2
+set expandtab
+set shiftwidth=2
+set cinoptions=>4,e0,n0,f0,{0,}0,^0,:s,=s,l0,gs,hs,ps,ts,+s,c3,C0,(2s,us,U0,w0,m0,j0,)20,*30
+
+"
+"set cindent
+"
+if has("autocmd")
+  autocmd FileType html,jsp,js,xml set ts=2
+  autocmd FileType html,jsp,js,xml set et
+  autocmd FileType html,jsp,js,xml set shiftwidth=2
+  autocmd FileType html,jsp,js,xml set cinoptions=>2,e0,n0,f0,{0,}0,^0,:s,=s,l0,gs,hs,ps,ts,+s,c3,C0,(2s,us,U0,w0,m0,j0,)20,*30
+endif
+
+" show filetypes in menu
+"let do_syntax_sel_menu = 1 | runtime! synmenu.vim | aunmenu &Syntax.&Show\ filetypes\ in\ menu
+
+"
+" set syntax type
+"
+syntax on
+"if &filetype != 'javacc'
+"    setlocal filetype=javacc
+"endif
+"set syntax=javacc
+"cal SetSyn("cpp")
+"cal SetSyn("vb")
+"cal SetSyn("perl")
+"cal SetSyn("awk")
+
+"
+" write backup file (*~) to c:\tmp
+"
+"set nobackup
+set undodir=~/tmp
+set backupdir=~/tmp
+set backup
+setlocal noswapfile
+"
+" no beeps & no visible bell
+"
+set vb t_vb=
+
+"
+" show line number
+"
+set number
+
+"
+"hide toolbar
+"see :help 'guioptions'
+"
+set guioptions-=T
+"set guioptions-=m
+
+set statusline=%F%m%r%h%w\ [FORMAT=%{&ff}]\ [TYPE=%Y]\ [ASCII=\%03.3b]\ [HEX=\%02.2B]\ [POS=%04l,%04v][%p%%]\ [LEN=%L]
+set laststatus=2 " always show the status line
+
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+"<22><><EFBFBD><EFBFBD>ѡ<EFBFBD><D1A1> textwidth <20>⣬ѡ<E2A3AC><D1A1> formatoptions ȷ<><C8B7><EFBFBD>˸<EFBFBD><CBB8>ı<EFBFBD><C4B1><EFBFBD>ʽ<EFBFBD><CABD><EFBFBD>йصĻ<D8B5><C4BB><EFBFBD>ѡ<EFBFBD><EFBFBD><EEA3AC><EFBFBD>õ<EFBFBD><C3B5><EFBFBD>ֵ<EFBFBD>У<EFBFBD>
+"    * t<><74><EFBFBD><EFBFBD><EFBFBD><EFBFBD> textwidth <20>Զ<EFBFBD><D4B6><EFBFBD><EFBFBD>У<EFBFBD>
+"    * c<><63><EFBFBD>ڣ<EFBFBD><DAA3><EFBFBD><EFBFBD><EFBFBD>Դ<EFBFBD><D4B4><EFBFBD><EFBFBD><EFBFBD>еģ<D0B5>ע<EFBFBD><D7A2><EFBFBD><EFBFBD><EFBFBD>Զ<EFBFBD><D4B6><EFBFBD><EFBFBD>У<EFBFBD><D0A3><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ʵ<EFBFBD>ע<EFBFBD><D7A2><EFBFBD><EFBFBD>ʼ<EFBFBD>ַ<EFBFBD><D6B7><EFBFBD>
+"    * r<><72><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ģʽ<C4A3><CABD><EFBFBD><EFBFBD>ע<EFBFBD><D7A2><EFBFBD>м<EFBFBD><D0BC><EFBFBD><EFBFBD>س<EFBFBD>ʱ<EFBFBD><CAB1><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ʵ<EFBFBD>ע<EFBFBD><D7A2><EFBFBD><EFBFBD>ʼ<EFBFBD>ַ<EFBFBD><D6B7><EFBFBD>
+"    * q<><71><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ʹ<EFBFBD>á<EFBFBD>gq<67><71><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ע<EFBFBD>ͽ<EFBFBD><CDBD>и<EFBFBD>ʽ<EFBFBD><CABD><EFBFBD><EFBFBD>
+"    * n<><6E>ʶ<EFBFBD><CAB6><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>б<EFBFBD><D0B1><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>е<EFBFBD><D0B5><EFBFBD>һ<EFBFBD>е<EFBFBD><D0B5><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ֺ<EFBFBD><D6BA>Ŀհ׾<D5B0><D7BE><EFBFBD><EFBFBD><EFBFBD><EFBFBD>롰2<EBA1B0><32><EFBFBD><EFBFBD>ͻ<EFBFBD><CDBB><EFBFBD><EFBFBD>Ҫ<EFBFBD><D2AA>autoindent<6E><74><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
+"    * 2<><32>ʹ<EFBFBD><CAB9>һ<EFBFBD>εĵڶ<C4B5><DAB6>е<EFBFBD><D0B5><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ʽ<EFBFBD><CABD><EFBFBD>ı<EFBFBD><C4B1><EFBFBD>
+"    * l<><6C><EFBFBD>ڵ<EFBFBD>ǰ<EFBFBD>г<EFBFBD><D0B3>ȳ<EFBFBD><C8B3><EFBFBD> textwidth ʱ<><CAB1><EFBFBD><EFBFBD><EFBFBD>Զ<EFBFBD><D4B6><EFBFBD><EFBFBD>¸<EFBFBD>ʽ<EFBFBD><CABD><EFBFBD><EFBFBD>
+"    * m<><6D><EFBFBD>ڶ<EFBFBD><DAB6>ֽ<EFBFBD><D6BD>ַ<EFBFBD><D6B7><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>У<EFBFBD><D0A3><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ر<EFBFBD><D8B1><EFBFBD>Ч<EFBFBD><D0A7><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ֻ<EFBFBD>ڿհ<DABF><D5B0>ַ<EFBFBD><D6B7><EFBFBD><EFBFBD><EFBFBD><EFBFBD>У<EFBFBD><D0A3><EFBFBD>
+"    * M<><4D><EFBFBD><EFBFBD>ƴ<EFBFBD><C6B4><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ʱ<EFBFBD><CAB1><EFBFBD><EFBFBD><EFBFBD>¸<EFBFBD>ʽ<EFBFBD><CABD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ֹ<EFBFBD>ʹ<EFBFBD>á<EFBFBD>J<EFBFBD><4A><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EEA3A9><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ǰһ<C7B0>еĽ<D0B5>β<EFBFBD><CEB2><EFBFBD><EFBFBD>һ<EFBFBD>еĿ<D0B5>ͷ<EFBFBD>Ƕ<EFBFBD><C7B6>ֽ<EFBFBD><D6BD>ַ<EFBFBD><D6B7><EFBFBD><EFBFBD>򲻲<EFBFBD><F2B2BBB2><EFBFBD><EFBFBD>ո񣬷dz<F1A3ACB7><C7B3>ʺ<EFBFBD><CABA><EFBFBD><EFBFBD><EFBFBD>
+"Vim <20><> formatoptions <20><>ȱʡֵ<CAA1>ǡ<EFBFBD>tcq<63><71><EFBFBD><EFBFBD>һ<EFBFBD><D2BB><EFBFBD>һ<EFBFBD><D2BB><EFBFBD> .vimrc <20>ļ<EFBFBD><C4BC>м<EFBFBD><D0BC><EFBFBD>һ<EFBFBD>С<EFBFBD>set formatoptions+=mM<6D><4D>
+"<22><>ȷ<EFBFBD><C8B7> Vim <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ַ<EFBFBD>֮<EFBFBD><D6AE><EFBFBD><EFBFBD><EFBFBD>ж<EFBFBD><D0B6><EFBFBD>Ҫ<EFBFBD><D2AA><EFBFBD>ո<EFBFBD><D5B8>Ĵ<EFBFBD><C4B4>ڣ<EFBFBD><DAA3><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ڴ󲿷<DAB4><F3B2BFB7><EFBFBD><EFBFBD><EFBFBD><EFBFBD>¿<EFBFBD><C2BF><EFBFBD><EFBFBD><EFBFBD>ȷ<EFBFBD>ش<EFBFBD><D8B4><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>¸<EFBFBD>ʽ<EFBFBD><CABD><EFBFBD><EFBFBD>
+"
+"
+"<22>س<EFBFBD><D8B3>Զ<EFBFBD><D4B6><EFBFBD><EFBFBD><EFBFBD>ע<EFBFBD>ͷ<EFBFBD><CDB7><EFBFBD><EFBFBD><EFBFBD>
+" vimhome/ftpplugin/java.vim & javascript.vim
+" "Set 'formatoptions' to break comment lines but not other lines,
+" "and insert the comment leader when hitting <CR> or using "o".
+" <20>޸<EFBFBD><DEB8><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
+" "setlocal formatoptions-=t formatoptions+=croql
+"set formatoptions=tq
+"
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+map <C-tab> gt
+map <C-left> gT
+map <C-right> gt
+
+"perl settings
+"<F7> for perl debugging
+map <F7> :w<CR>:!perl -wd "%"<CR>
+"<F8> for perl syntax checking (autosave first)
+map <F8> :w<CR>:!perl -wc "%"<CR>
+"<F9> to run by perl (autosave first) "",'' are both ok
+map <F9> :w<CR>:!perl "%"<CR>
+
+set complete-=i
+
+" <20><><EFBFBD><EFBFBD><EFBFBD>Զ<EFBFBD>ע<EFBFBD><D7A2>
+autocmd FileType * setlocal formatoptions-=c formatoptions-=r formatoptions-=o
+
+"<22><>ʼʹ<CABC><CAB9>Vundle<6C>ı<EFBFBD><C4B1><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+set nocompatible
+filetype off
+set rtp+=~/.vim/bundle/vundle/
+call vundle#rc()
+
+"ʹ<><CAB9>Vundle<6C><65><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Vundle
+"dos install command : vi +BundleInstall +qall
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+Bundle 'gmarik/vundle'
+"PowerLine<6E><65><EFBFBD><EFBFBD> ״̬<D7B4><CCAC><EFBFBD><EFBFBD>ǿչʾ
+Bundle 'L9'
+"Bundle 'Lokaltog/vim-powerline'
+"Bundle 'mattn/emmet-vim'
+"Bundle 'vim-scripts/AuthorInfo'
+"Bundle 'Shougo/neocomplcache'
+"Bundle 'FuzzyFinder'
+"Bundle 'edsono/vim-matchit'
+"Bundle 'The-NERD-tree'
+"Bundle 'The-NERD-Commenter'
+"Ag searcher
+"Bundle 'rking/ag.vim'
+"Bundle 'scrooloose/syntastic'
+"Bundle 'TeTrIs.vim'
+"Bundle 'vim-scripts/calendar.vim--Matsumoto'
+"Bundle 'mbriggs/mark.vim'
+"Bundle 'skammer/vim-css-color'
+"Bundle 'vim-scripts/css3-mod'
+Bundle 'ybian/smartim'
+
+"Vundle<6C><65><EFBFBD>ñ<EFBFBD><C3B1><EFBFBD> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
+filetype plugin indent on
+
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+let g:smartim_default = 'com.apple.keylayout.US'
+let g:smartim_disable = 1
+
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+"Bundle config
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+" Vim-powerline config
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+"vim<69><6D>һ<EFBFBD><D2BB>״̬<D7B4><CCAC> <20><><EFBFBD><EFBFBD>powline<6E><65><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>״̬<D7B4><CCAC>
+set laststatus=2
+set t_Co=256
+let g:Powline_symbols='fancy'
+
+"emmet-vim config
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+let g:user_emmet_expandabbr_key='<c-e>'
+"let g:user_emmet_expandabbr_key='<Leader>e'
+let g:user_emmet_complete_tag=1
+let g:user_emmet_next_key='<c-n>'
+let g:user_emmet_prev_key='<c-p>'
+
+"authorinfo
+let g:vimrc_author='Chen Gan'
+let g:vimrc_email='gavin.chan.hz@gmail.com'
+let g:vimrc_homepage='xxxx.xxx.net/gavin'
+"???  error - E492
+"ͨ<><CDA8>bundle<6C><65>װ<EFBFBD>ú<EFBFBD><C3BA><EFBFBD><EFBFBD>޸<EFBFBD>C:\Users\gavin\.vim\bundle\AuthorInfo<66>ļ<EFBFBD><C4BC><EFBFBD>ftpplugin Ϊplugin<69><6E>solved 
+nmap <F4> :AuthorInfoDetect<cr> 
+
+"neocomplcache config
+let g:neocomplcache_enable_at_startup = 1
+let g:neocomplcache_force_overwrite_completefunc = 1
+let g:neocomplcache_enable_ignore_case=1
+" set the max list in the popup menu. increase the speed
+let g:neocomplcache_max_list=20
+inoremap <expr><TAB> pumvisible() ? "\<C-n>" : "\<TAB>"
+
+"NERDTree
+let NERDChristmasTree=1
+let NERDTreeAutoCenter=1
+let NERDTreeMouseMode=2
+let NERDTreeShowBookmarks=1
+let NERDTreeShowFiles=1
+let NERDTreeShowHidden=0
+let NERDTreeShowLineNumbers=1
+let NERDTreeWinPos='left'
+let NERDTreeWinSize=40
+let NERDTreeIgnore=['\.vim$', '\~$', '\.o$', '\.d$', '\.a$']
+let mapleader="," 
+"<22><><EFBFBD><EFBFBD>,n<><6E><EFBFBD>߰<EFBFBD>F9ʱ<39><CAB1><EFBFBD><EFBFBD>/<2F>ر<EFBFBD>NERDTree
+nnoremap <silent> <Leader>n  :NERDTreeToggle <CR> 
+nmap <silent> <F9> :NERDTreeToggle <cr>
+
+"calendar-vim
+"hotkey <leader>cal,ˮƽ<CBAE><C6BD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><leader>caL
+let g:calendar_diary = "E:/gavin/note"  "<22><><EFBFBD><EFBFBD><EFBFBD>ռǵĴ洢·<E6B4A2><C2B7>
+let g:calendar_monday = 1               "<22><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>һΪ<D2BB><CEAA>ʼ
+let g:calendar_focus_today = 1          "<22><><EFBFBD><EFBFBD><EFBFBD>ڵ<EFBFBD><DAB5><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
+"let g:calendar_mark = 'left-fit'       "<22><><EFBFBD><EFBFBD><EFBFBD><EFBFBD>*<2A><><EFBFBD><EFBFBD><EFBFBD>ֿɿ<D6BF><C9BF><EFBFBD>
+let g:calendar_mark = 'right'           "<22><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ú<EFBFBD><C3BA><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>д<EFBFBD><D0B4>־<EFBFBD><D6BE><EFBFBD>޸ij<DEB8>right<68><74><EFBFBD><EFBFBD>
+"let g:calendar_mruler = 'һ<><D2BB>,<2C><><EFBFBD><EFBFBD>,<2C><><EFBFBD><EFBFBD>,<2C><><EFBFBD><EFBFBD>,<2C><><EFBFBD><EFBFBD>,<2C><><EFBFBD><EFBFBD>,<2C><><EFBFBD><EFBFBD>,<2C><><EFBFBD><EFBFBD>,<2C><><EFBFBD><EFBFBD>,ʮ<><CAAE>,ʮһ<CAAE><D2BB>,ʮ<><CAAE><EFBFBD><EFBFBD>' " <20><><EFBFBD>ģ<EFBFBD><C4A3><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>޸<EFBFBD>
+"let g:calendar_wruler = '<27><> һ <20><> <20><> <20><> <20><> <20><>'
+"let g:calendar_navi_label = '<27><>ǰ,<2C><><EFBFBD><EFBFBD>,<2C><><EFBFBD><EFBFBD>'
+let g:calendar_datetime = 'statusline' " can set 'title', 'statusline', '' for this option.
+
+"mark
+"hotkey <leader>m   -- mark
+"       <leader>mc  -- clear mark
+nmap <unique> <silent> <Leader>mc <Plug>MarkClear
+
+"syntastic
+let g:syntastic_check_on_open=1
+"let g:syntastic_phpcs_conf='--tab-width=4 --standard=CodeIgniter'
+"let makeprg='php -l -d error_reporting=E_ALL -d display_errors=1'
+
+" css3_mod
+let g:css_default_sync=1
+
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
+

20200811会议纪要.md

@@ -0,0 +1,33 @@
+
+关于天翼看家运维工作优化的会议
+
+为进一步理顺天翼看家维护流程，落实解决业务开展过程中碰到的问题，2020年8月11日上午，省公司召开天翼看家运维工作协调会，王淑春副总经理出席会议并提出指示，科创部总经理沈毅纲主持会议，会议主要就资源申请及网信安、支撑维护流程、CT云资源三方面存在的问题及优化方案做了汇报，与会部门讨论了解决方案和后续推进要求。现将会议关键事项纪要如下：
+一、针对云资源申请中存在的操作系统部署较慢问题，请网发部牵头推进集成公司优化部署效率，并在后续探索采用自动化从软件仓库拉取操作系统的部署手段。
+二、为提升安扫阶段中的人工渗透效率，安全管理部提出落实订单式人工渗透需求，SOC确保在24小时内完成人工渗透工作。
+三、会议明确，为避免重复扫描工作，11个边缘节点平台软件同一版本只做一次扫描，通过安全扫描后，其他节点同一版本视同通过，，研发分公司承诺同步修复所有节点中扫描出现的问题。另研发分公司与SOC明确接口人，以邮件方式同步软件版本信息。
+四、为统一维护入口，便于闭关管理，会议明确，把天翼看家业务纳入10000号受理。在当前平台和资源问题占比较高及设备量不大的情况下，10000号预处理后，省运维团队（？）第一界面接应报障，QQ群等即时通讯工具辅助手段暂时保留。平稳运行并上量后，再考虑优化流程，第一接单单位下沉到分公司。请10000号与企信部协同落地，并测试穿越流程。
+五、会议讨论了CT云资源存在的监控、管理、资源隔离及资源发放手段不足等问题。会议明确，请网发部组织集成公司相关领导加强集成公司在浙江的人员投入，并协商对策，针对此类尽快提出解决方案。同时，研发分公司与NOC开展双向监控，研发分公司可以把高等级服务监控告警对接智能网关派单。
+
+出席：
+记录：
+
+
+为推进 2018 年网络安全重点工作，2018 年 3 月 19 日在元
+华 5020 会议室，网络运营事业部牵头组织了 2018 年网络安全
+重点工作协调会，参加会议的有市场部、政企客户事业部、企
+业信息化事业部、各运营中心、省传输局、浙江省公众信息产
+业有限公司、浙江公众数据通信有限公司的网络安全责任人。
+会上网络运营事业部宣贯了 2018 年工信部和集团的考核要求。
+与会代表就 18 年网络安全重点工作进行了讨论，明确了各相关
+单位网络安全联络员名单，同时对网络安全事件快速处臵流程
+优化达成一致意见。现将会议内容纪要如下：
+
+为进一步推进和落实公司合规管理要求，针对目前存在未
+完成合同签订但实际已发生的经济业务、且业务部门需要发起
+支付报账的情况，企业发展（法律）部、审计部、财务部及财
+务共享服务中心进行了专题讨论，对以下事项进行了明确：
+
+
+
+
+

20210903work.md

@@ -0,0 +1,35 @@
+
+# 保障部
+
+## 支撑&重保
+
+### 支撑
+- 云宽监控纳入，监控项全面覆盖
+- 支撑文档，尤其是云宽项目支撑文档需丰富，FAQ
+- 云宽10000号对接工作情况跟进
+- 人员能力提升持续推进
+
+### 重保
+- 统一入口
+- 重保安排
+    - 明确保障等级，保障范畴
+      - 一级，可用性保障，小型、关注度不高、影响面不大，如支局营销
+      - 二级，行业会议等，故障可能造成普通客户负面评价，如某阿里造物节
+      - 三级，有重大影响的大型保障，故障可能造成政府部门的负面评价，或较大舆情压力，如G20，互联网大会，金砖
+    - 保障方案，二级及以上需提供保障方案
+      - 值班安排
+      - 保障团队：监控、现场、远程、运维、研发
+      - 技术方案（如需，比如特通等特殊需求）
+          - 监控
+          - 运维&应急
+          - 安全
+      - 保障制度
+          - 值班制度
+          - 封网要求
+      - 外部对接（如云资源）
+    - 应急
+        - 应急预案
+        - 应急演练
+
+### 上线
+

20240418.md

@@ -0,0 +1,6 @@
+
+## 20240418
+
+所有包需要解头？不同摄像头？
+
+

5g.md

@@ -0,0 +1,27 @@
+# 5G
+
+
+### questions
+- CU/DU部署方案？
+
+
+### 功能实体
+在5G网络中，接入网不再是由BBU、RRU、天线这些东西组成了。而是被重构为以下3个功能实体：
+- CU（Centralized Unit，集中单元）
+  CU：原BBU的非实时部分将分割出来，重新定义为CU，负责处理非实时协议和服务。
+- DU（Distribute Unit，分布单元）
+  DU：BBU的剩余功能重新定义为DU，负责处理物理层协议和实时服务。
+- AAU（Active Antenna Unit，有源天线单元）
+  AAU：BBU的部分物理层处理功能与原RRU及无源天线合并为AAU。
+
+<br> ![img](imgs/5g/5g1.jpg)
+<br> ![img](imgs/5g/5g2.jpg)
+EPC（就是4G核心网）被分为New Core（5GC，5G核心网）和MEC（移动网络边界计算平台）两部分。MEC移动到和CU一起，就是所谓的“下沉”（离基站更近）。
+
+
+### references
+1. [5G核心网](https://app.yinxiang.com/fx/a7afa44c-dfc6-4140-8a41-deefe2c6cb66)
+1. [NFV的五大矛盾](https://app.yinxiang.com/fx/0b3167c1-d976-4c5b-a54f-b30a2fb6a3fe)
+1. [E2E Network Slicing](https://app.yinxiang.com/fx/5b4b59cd-6b79-4b80-b6d3-26904270f58b)
+1. []()
+

AOP.md

@@ -0,0 +1,35 @@
+
+# AOP & IOC
+---
+
+## :red_circle: AOP
+
+## :red_circle: IOC
+IoC(Inversion of Control) 
+![4236553-c415d1c39ed74772.png](https://i.loli.net/2020/05/13/uDnFJUXYAlSogh4.png)
+- DL 已经被抛弃，因为他需要用户自己去是使用 API 进行查找资源和组装对象。即有侵入性。
+- DI 是 Spring 使用的方式，容器负责组件的装配。
+
+![u_4258379052,1368074021_fm_26_gp_0.png](https://i.loli.net/2020/05/13/kSFnAjGUgK2YeMZ.png)
+![timg.jpg](https://i.loli.net/2020/05/13/SOxPgI3up25tbv8.jpg)
+
+**疑问：**
+- 通过xml配置或容器方式生成实例替代调用关系生成实例，解耦没错，怎么叫反转？A要用到B类，需要实例化B，IOC则是把实例化过程交给容器，A只管使用，不管实例化过程。
+
+## :red_circle: 一些概念
+### java 注解(Annotation) & python 装饰器(decorator)
+python这里的装饰器是一个有逻辑的，可以执行的函数，只不过其写法有些特殊要求；
+Java里面的Annotation只是个标记，需要其他代码来“根据标记执行“。
+
+### POJO (Plain Ordinary Java Object) &  java bean
+POJO是一个简单的普通的Java对象，它不包含业务逻辑或持久逻辑等，但不是JavaBean、EntityBean等，不具有任何特殊角色和不继承或不实现任何其它Java框架的类或接口。具有一部分getter/setter方法的那种类就可以称作POJO。
+
+
+## :red_circle: references
+- [IOC概念详解](https://www.jianshu.com/p/745a17f519a6)
+- [IOC Spring揭秘阅读总结](https://www.jianshu.com/p/39f15ced9a74)
+- [什么是面向切面编程AOP？](https://www.zhihu.com/question/24863332)
+
+
+-- 20200514 复习
+

CorporateCulture.md

@@ -0,0 +1,9 @@
+# Corporate Culture Tesla
+
+1. Move fast
+2. Do the impossbile
+3. Constantly innovate
+4. Reason from the "First principles"  - 第一性原则，正本清源
+5. think like owners
+6. We are ALL IN
+

HW.md

@@ -0,0 +1,50 @@
+
+# HW
+
+# 20210323 侯亮
+## 系统评估阶段
+- 互联网
+- 内网
+    不要求漏洞全部修复
+    快速发现攻击，快速处置，十五分钟，黄金时间
+- 社会工程评估 
+    特殊时期，员工网络安全意识
+    特殊手段
+
+## 分析确认阶段
+分析报告，字号字体
+
+红队：
+- 核心数据，服务器权限，进入内网
+- OA系统，重点防范
+- VPN **护网专版VPN**
+- 蜜罐系统，机器对抗机器中运用，对人的攻击的意义逐步减小，（去年蜜罐自身被攻破进入内网，机器比较难发现蜜罐）
+- 人员安全意识
+
+### 红队评估
+- day漏洞
+- 弱口令
+- SQL注入
+- xss
+
+### 内网，安全设备产生安全事故
+- 应用服务  OA，邮件、VPN
+
+### 社工
+
+### 邮件系统
+- 最新版本
+
+## 案例
+- 前期侦查：DNS、域名、资产收集、敏感信息
+  防守：
+- 内部侦查：
+
+
+# 20210323 
+regeorg
+arp -a
+
+cobalStrike 植入后门
+
+

LICENSE

@@ -0,0 +1,674 @@
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                            Preamble
+
+  The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
+
+  The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+  To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too, receive
+or can get the source code.  And you must show them these terms so they
+know their rights.
+
+  Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+  For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+  Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+  Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+                       TERMS AND CONDITIONS
+
+  0. Definitions.
+
+  "This License" refers to version 3 of the GNU General Public License.
+
+  "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+  "The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
+
+  To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+
+  A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+  To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+  To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+  An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+  1. Source Code.
+
+  The "source code" for a work means the preferred form of the work
+for making modifications to it.  "Object code" means any non-source
+form of a work.
+
+  A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+  The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+  The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+  The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+  The Corresponding Source for a work in source code form is that
+same work.
+
+  2. Basic Permissions.
+
+  All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+  You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+  Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+  No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+  When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+  4. Conveying Verbatim Copies.
+
+  You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+  You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+  You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under section
+    7.  This requirement modifies the requirement in section 4 to
+    "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+  A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+  You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the
+    Corresponding Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in accord
+    with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to the
+    Corresponding Source in the same way through the same place at no
+    further charge.  You need not require recipients to copy the
+    Corresponding Source along with the object code.  If the place to
+    copy the object code is a network server, the Corresponding Source
+    may be on a different server (operated by you or a third party)
+    that supports equivalent copying facilities, provided you maintain
+    clear directions next to the object code saying where to find the
+    Corresponding Source.  Regardless of what server hosts the
+    Corresponding Source, you remain obligated to ensure that it is
+    available for as long as needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission, provided
+    you inform other peers where the object code and Corresponding
+    Source of the work are being offered to the general public at no
+    charge under subsection 6d.
+
+  A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+  A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+  "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+  If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+  The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+  Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+  7. Additional Terms.
+
+  "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+  When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+  Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material, or
+    requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors or
+    authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions of
+    it) with contractual assumptions of liability to the recipient, for
+    any liability that these contractual assumptions directly impose on
+    those licensors and authors.
+
+  All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+  If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+  Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+  8. Termination.
+
+  You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+  However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+  Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+  Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+  You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+  Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+  An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+  You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+  11. Patents.
+
+  A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+  A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+  Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+  In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+  If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+  If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+  A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+  Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+  If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+  Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU Affero General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the GNU Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+
+  14. Revised Versions of this License.
+
+  The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+  Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+  If the Program specifies that a proxy can decide which future
+versions of the GNU General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+  Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+  15. Disclaimer of Warranty.
+
+  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+  If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation, either version 3 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+  If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+    <program>  Copyright (C) <year>  <name of author>
+    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, your program's commands
+might be different; for a GUI interface, you would use an "about box".
+
+  You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU GPL, see
+<http://www.gnu.org/licenses/>.
+
+  The GNU General Public License does not permit incorporating your program
+into proprietary programs.  If your program is a subroutine library, you
+may consider it more useful to permit linking proprietary applications with
+the library.  If this is what you want to do, use the GNU Lesser General
+Public License instead of this License.  But first, please read
+<http://www.gnu.org/philosophy/why-not-lgpl.html>.

aiops.md

@@ -0,0 +1,8 @@
+
+# 自动化运维 & AIOps
+
+
+
+### reference
+- [AIOps是如何在腾讯IEG体系化推进和普及的？](https://zhuanlan.zhihu.com/p/435229129)
+

backup.md

@@ -0,0 +1,6 @@
+
+# backup
+
+mysql backup
+- xtrabackup
+- mysqldump

branch_mode.md

@@ -0,0 +1,36 @@
+
+# 开发模式
+
+常见的Git分支模式:
+- TBD（主干开发模式）
+- Git-Flow模式
+- Github-Flow模式
+- Gitlab-Flow模式
+
+## TBD
+为了保证主干代码的质量，避免出现工程师合入到主干的代码break掉主干的情况，Google 采取了以下实践：
+- 代码合入事件触发通过持续集成，确保合入到主干的代码经过充分且必要测试；
+- 通过 Bazel 实现相关代码（指依赖变更代码的代码）的精准测试；
+- **至少 2 个合资格的 reviewer （代码评审人）的 LGTM（Look Good To Me），才允许代码合入主干；**
+
+腾讯某 BG 在 2018 年开始的“930 变革”后，在各试点团队推动主干开发（注：并未全公司普遍采用），具体的举措包括：
+- 以度量牵引：通过对特性分支）的生命期监控和预警，实现非主干分支的生命期缩短，倒逼开发团队采用主干开发；
+- 投大力气统一 BG 内的持续集成工具、开发自动化测试平台；
+- 制定了 7 大编程语言的编码规范，并自研代码静态扫描工具；
+- 并参考 Google 推行代码可读性（Readability）、可测试性（Testability）认证制度；
+- 强力推行 CR （代码评审）制度，确保代码的可读性（命名、代码风格、设计、复杂度）。
+
+效果：
+- 质量提升：代码质量从可测量的维度得到明显提升（代码规范率、单元测试覆盖率）；
+- 迭代速度提升：试点团队的迭代周期从 4 周或 2 周提升至 1 周；
+- 代码从“私有”变“公有”：通过代码评审制度，提高了代码可读性，使代码从个人拥有（只有写代码的人能看懂），变成团队拥有（整个团队都能看懂）；这一点对于企业非常重要，接手过别人代码的程序们都有感受；
+- 代码的自动化测试覆盖率提升明显，为未来的重构构筑了一张安全网；
+
+有些中小企业的技术决策者非常认可持续集成 / 持续交付的理念，从而更希望采用主干开发，但对于主干开发的缺点（或说弥补缺点的成本）存在顾虑。对此，我有如下建议：
+- 基础架构要求：可以考虑采用开源软件，如持续集成采用 Jenkins、Travis CI、Gitlab CI 等，通过简单部署可以投入使用；同时配合代码静态分析工具（如 SonarQube、CheckStyle），确保代码基本质量过关；
+- 自动化测试要求：工具上不存在障碍，现代编程语言（如 java、go、c++）都有内建或第三方的单元测试框架；难点只在于成员的开发习惯，可以通过测试覆盖率工具，以增量覆盖率指标保证新增代码都有完备的自动化测试，从而逐步改变团队的研发文化；
+- 代码评审要求：开源的 Git 服务器（如 Gitlab）基本都支持 push hook，配合开源的 Gerrit 等 CR 工具，可以实现在代码推送（push）或 pull request（合入请求）时触发 1 个代码评审请求，实现评审通过后，代码才正式合入的功能；剩下的就是研发文化问题了，需要在团队内部推行代码规范、代码可读性等宣导和教育工作；
+- 发布时的特性开关：如果要求不高，可以通过代码 hard code 一个常量作为特性开关；如果要求高，也有开源的特性开关（比如：unleash、piranha、flipper）工具可供选择。参考上述建议，并充分认识到主干开发的成本和困难的情况下，中小企业开发团队也并非不可以考虑主干开发的实践。
+
+## reference
+- [Google 和腾讯为什么都采用主干开发模式？](https://36kr.com/p/1218375440667012)

certificates.md

@@ -0,0 +1,35 @@
+# 认证培训
+
+证书|描述
+--|--
+TOGAF|TOGAF支持开放、标准的SOA参考架构，同时支持其他不同的架构风格，如传统的面向对象、CS、或BS三层架构风格。TOGAF的元模型已经支持面向服务的原则，在建立业务架构时，可从目标逐步分解为功能、流程、及业务服务，业务服务将通过信息系统服务及应用构件来实现。
+CISA|CISA(Certified Information Systems Auditor，中文为国际信息系统审计师)认证是由信息系统审计与控制协会ISACA(Information Systems Audit and Control Association)发起的，是信息系统审计、控制与安全等专业领域中取得成绩的象征。
+CISSP|
+CISP|
+CGEIT|
+COBIT5|
+ITIL|
+RHCA|
+
+---
+
+若欲取得红帽RHCA认证，您必须通过以下考试中的任意5门考试：
+
+考试代码|认证名称
+--|--
+EX210|红帽 OpenStack 认证系统管理员考试
+EX220|红帽混合云管理专业技能证书考试
+EX236|红帽混合云存储专业技能证书考试
+EX248|红帽认证 JBoss 管理员考试
+EX280|红帽平台即服务专业技能证书考试
+EX318|红帽认证虚拟化管理员考试
+EX401|红帽部署和系统管理专业技能证书考试
+EX413|红帽服务器固化专业技能证书考试
+EX436|红帽集群和存储管理专业技能证书考试
+EX442|红帽性能调优专业技能证书考试
+
+---
+
+证书名称|取得时间|考试地点|培训机构|费用
+--|--|--|--|--
+2019/12/25 | devops master | 上海 | 艾威培训 | 12000

chuangxin.md

@@ -0,0 +1,83 @@
+
+# 创新成果
+---
+
+## 实习员工课题
+
+### 云原生（容器）安全防护 - 王元星
+- 现状&意义&目标
+    - 云原生的主要安全问题
+    - 了解目前的做法、工具、不足
+    - 目标：提升容器安全，如何把容器安全落实到安全基线中
+- 方向&内容
+
+- 思路&方法&创新点
+    - 自动化运维中提供容器/云原生安全检查模块，能够列出安全隐患及整改建议
+    - 自动化运维中可以勾选一键修复（需审核）
+
+- 产出&应用
+    - 云原生/容器安全标准规范，以及在运维实践中的执行情况（参考资料需列入文献）
+    - 工具：容器安全的自动检查，容器安全基线自动执行（运维开发提供测试模块，并做开发指导）
+
+### AIOPS故障自愈 - 闫莉婕
+- 现状&意义&目标
+    - devops现状，到AIOps演进路径，达到AIOps的工作
+    - 目标：AIOps这个课题比较大，结合devops中运维角色，从现实工作入手，基于判断和算法做自愈。
+
+- 方向&内容
+
+- 思路&方法&创新点
+    - 生产中大量的告警的共性提炼
+    - 阈值设定 - 策略 - 执行
+    - *基于学习算法 - 生成策略 - 执行，这个要求比较高，且不一定可靠，可以尝试*
+
+- 产出&应用
+    - AIOps价值观、标准规范，帮助提升运维水平
+    - 自动化运维中自愈流程固化，方便扩展，标准化；在加监控中能够关联自愈动作
+    - 触发 - 策略 - 动作的分离
+
+---
+
+### 总体要求
+#### 提纲
+- 现状
+- 意义&目标
+- 方向&内容
+- 思路&方法&创新点
+- 产出&应用
+
+#### 要求
+- 区别于学校研究
+    - 结合部门工作
+    - 有一定创新性
+    - 面不必太广
+    - 能够解决实际问题，有实践，有深度
+
+---
+## 小微创新
+流程改进，工作方法改进。
+快速部署？效率提升。
+SDN网络技术相关。
+日志系统？
+网络发现和拓扑管理？调用链发现？
+
+支撑：
+- 通过流程改造，工作法，提升效率。
+- 通过小工具/微创新的应用，达到效率改善
+
+
+成果名称|所属领域|完成时间|研发单位
+--|--|--|--
+安全基线一键自动化修复工具|网信安全||运维支撑中心
+portal页面防篡改工具|网信安全||运维支撑中心
+WiFi平台双DC业务一键迁移容灾|运营维护(O域)||运维支撑中心
+视联网边缘节点容器化自动化部署工具|运营维护(O域)||运维支撑中心
+运维任务批量自动化下发执行工具|运营维护(O域)||运维支撑中心
+资源采集监控系统|运营维护(O域)||运维支撑中心
+软硬件自动化巡检工具|运营维护(O域)||运维支撑中心
+云原生（容器）安全防护|网信安全||运维支撑中心
+AIOPS故障自愈|运维||运维支撑中心
+*基于云原生的主动防护能力提升实践*|运维||运维支撑中心
+*基于混沌技术的高效应急演练体系建设*|运维||运维支撑中心
+
+

cloudbroadband.md

@@ -0,0 +1,16 @@
+
+# 云宽带分享
+
+## 
+
+p2 - 云宽带故障串入
+
+五要素:
+
+cvlan，pvlan，port => 隧道
+40GB
+
+大屏，监控系统
+
+
+

cloudnative.md

@@ -0,0 +1,62 @@
+
+# 云原生
+
+目前形成云原生理解上的最大共识概括为**4个核心要点**：DevOps+持续交付+微服务+容器，即基于这”4件套”构建的应用我们暂且认为就是云原生应用了。同时可以享受到云端极为丰富的PaaS组件，如业务后续使用到的数据库、缓存、中间件、存储、CDN等等，并且具备无缝在不同云厂商间透明迁移的能力。
+
+微服务架构为基础，构建的集代码管理、服务开发、运维发布、服务运营为一体的一站式开发运营平台,实现了真正意义上的DevOps服务闭环，贯穿了服务交付的CI、CD、CO环节，得益于公司内外部更多优秀组件的集成，包括TKE、蓝盾、QCI、Envoy等。
+
+## **云原生运维转型思维**
+这几年运维界听到最多的几句话：“云计算会淘汰掉运维！整个运维行业可能被干掉！再不转换运维就要丢饭碗”，诸如此类。那真相到底是什么？行业有一个共识，即运维工作本身交付的是一种服务，下面举一个可能不太恰当的例子，或者可以帮助大家找到答案。
+云计算时代好比组装一辆汽车，根据客户的需要，通过PaaS能力选择匹配的引擎、车轮、离合器、 悬架、车控制系统等进行拼装。客户不用关心汽车各元部件的实现原理，最终获得是一辆满足自身要求的汽车。光有了汽车是玩不转的。还需要有修路、加油站、交通控制等服务体系，运维就是承担这个角色。
+相比传统运维，确实是少了自己采购元组与组装的工作。到了后云计算时代（云原生），出现了一个DevOps公司，引入新技术与理念，声称已经将修路、加油站、交通控制等环节都打通了，形成了一体化服务能力，并邀请运维哥一起加入创业。在这个阶段，运维哥出去单干，大概率会翻车。
+但加入 DevOps 公司，运维的价值到底还有什么呢？因此，升级与转型是必然的，例如将普通国道升级成高速公路；实现客户在高速路上不停车换轮胎；贴近并理解客户，规划行程中所需的服务来提升客户体验；通过提升智能化水平，连接交通管制，缩短航程，避开损坏路段等等。相信大家心中已经有自己答案了。回到原点的灵魂拷问：“云原生背景下，运维不做转型会不会死？”，“运维要如何快速自救和升级？”。
+
+## **文化层面**
+以下几点是我们中心内部实行的几个机制，供作参考，因不同团队间存在一定差异，此处不展开说明。
+开发与运维成立FT虚拟团队，实现**组织融合**；
+开发或运维侧的例会、技术分享、事件复盘，FT成员全程参与；
+项目立项时，运维接口人需要做“**左移**”，即提前参与技术架构讨论，有助于运维的问题提前在方案讨论或开发阶段提前暴露，有效做好防范与规避；
+建立收集各方反馈问题与建议的机制与渠道，有效将好的想法影响至平台下个版本的迭代中，实现持续改进与优化。
+
+## **云原生运维目标**
+在云原生背景下，我们对运维体系进行了升级，在原有基础运维能力之上确定了以下几个目标：
+具备服务全链路质量监控覆盖，涵盖数据域与业务域
+具备一定智能化的资源动态调度、伸缩机制
+具备一定的故障预警、根因分析、问题定位能力
+服务具备在交付不同阶段（测试、预发布、运营）抵御异常的能力
+具备资源高效交付的流程机制与快速上线的能力
+具备多云的资源编排与管理的能力
+具备业务快速上云的机制，确保切换过程的高可用性
+
+确定了运维能力升级指导思想：**基于运维编排的云原生实例化**。广义而言，运维的本质就是多个运营事件的有机串联，来达到质量、效率、成本、安全多维收益，而编排是实现有机串联的有效手段，除了可以沉淀运维经验外，还可以有效实现共享。
+
+CG: 一定要牢记**可沉淀、可积累、可共享**，形成迭代上升。
+
+## **CI/CD**
+
+## **平台能力**
+
+**云端一切皆有操作**
+- 云资源编排，编排对象是各类云资源，包括公有云、私有云等，采用terraform来实现多云基础设施的编排，可以覆盖腾讯云、阿里云、AWS、私有云等等。
+- kubernetes编排，编排对象是k8s集群资源，采用Helm/YAML进行编排。
+- 作业编排，编排对象主要是主机节点，对应的操作任务编排，调用现有的蓝鲸job作业平台。
+🐋[蓝鲸作业平台](https://bk.tencent.com/docs/document/5.1/7/3787)
+
+运维编排三层之间如何串联？我们采用了开源的蓝鲸标准运维作为编排引擎，将不同的三层编排串联，打破从前跨云、跨平台各种割裂的操作界限，提升运维效率，一切皆编排，并能将编排任务沉淀为能力模板传承交接。
+
+例如上图的场景，我们需要扩容一个现网的TKE业务集群，从基础设施层的资源采买，到容器服务初始化部署，和一些集群特性作业操作等均一站式运维编排完成，操作时长从4小时优化到30分钟内，而且集群再次扩容只需简单修改几个编排参数执行，避免了繁琐重复的操作。在玄图平台能力中将通过自助开发可编排的原子（包括操作、接口、算法等），一切操作皆编排。
+
+
+## **云原生监控**
+
+## **云原生业务全链路跟踪（血缘关系链）**
+
+## **混沌工程**
+Adrian Cockcroft给出了另一个定义则是：混沌工程是一种确保失败所带来的影响能够被减少的实验。
+
+这里我们TKE集群中的服务设计了CPU负载注入演习，启动实验后，CPU按预期提升，当CPU持续高负载时，服务正常且触发自动扩容，无请求超时用户无感知，符合预期，加深了团队对系统可靠性的理解和认知。
+
+## **优势**
+
+## reference
+- [云原生背景下的运维价值思考与实践](https://cloud.tencent.com/developer/article/1753976)

cmder.md

@@ -0,0 +1,21 @@
+
+# cmder
+
+### 修改提示符
+C:\cmder\vendor\clink.lua
+
+```
+-- CG 
+local cmder_prompt = "\x1b[1;32;40m{cwd}{git}{hg}{svn}>"
+clink.prompt.value = string.gsub(cmder_prompt, "{cwd}", cwd)
+```
+### 修改aliases
+C:\cmder\config\user_aliases.cmd
+
+```
+e.=explorer .
+
+history=tail -n 200 "%CMDER_ROOT%\config\.history"
+ll=ls -al --show-control-chars --color $*
+enw=d: && cd d:\wisim\wisim.qt4
+```

compile.md

@@ -0,0 +1,13 @@
+
+# c
+
+Makefile.am
+autoscan
+   mv configure.scan configure.ac
+
+autoreconf
+
+----
+qmake project
+qmake
+make

config_k8s.md

@@ -0,0 +1,221 @@
+
+# K8S yaml文件详解
+
+## K8S 创建资源的方式
+
+K8S有两种创建资源的方式：kubectl 命令和 yaml 配置文件。
+
+kubectl命令行：最为简单，一条命令就OK.
+
+yaml配置文件：提供了一种让你知其然更知其所以然的方式。优势如下：
+
+- 完整性：配置文件描述了一个资源的完整状态，可以很清楚地知道一个资源的创建背后究竟做了哪些事；
+- 灵活性：配置文件可以创建比命令行更复杂的结构；
+- 可维护性：配置文件提供了创建资源对象的模板，能够重复使用；
+- 可扩展性：适合跨环境、规模化的部署。
+
+## yaml 是什么？
+
+yaml 是一种用来写配置文件的语言，没错，它是一门语言。如果你用过 json，那么对它就不会陌生，yaml 又被称为是 json 的超集，使用起来比 json 更方便。
+结构上它有两种可选的类型：Lists 和 Maps。List 用 -（破折号） 来定义每一项，Map 则是一个 key:value 的键值对来表示。
+YAML语法规则：
+
+大小写敏感
+使用缩进表示层级关系
+缩进时不允许使用Tal键，只允许使用空格
+缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
+"#"表示注释，从这个字符一直到行尾，都会被解析器忽略　
+"---"" 为可选的分隔符　
+
+在Kubernetes中，只需要知道两种结构类型即可：
+- Lists
+- Maps
+
+### kubernetes yaml 文件模板：
+
+yaml格式的pod定义文件完整内容：
+
+```
+apiVersion: v1       #必选，版本号，例如v1
+kind: Pod       #必选，Pod
+metadata:       #必选，元数据
+  name: string       #必选，Pod名称
+  namespace: string    #必选，Pod所属的命名空间
+  labels:      #自定义标签
+    - name: string     #自定义标签名字
+  annotations:       #自定义注释列表
+    - name: string
+spec:         #必选，Pod中容器的详细定义
+  containers:      #必选，Pod中容器列表
+  - name: string     #必选，容器名称
+    image: string    #必选，容器的镜像名称
+    imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像
+    command: [string]    #容器的启动命令列表，如不指定，使用打包时使用的启动命令
+    args: [string]     #容器的启动命令参数列表
+    workingDir: string     #容器的工作目录
+    volumeMounts:    #挂载到容器内部的存储卷配置
+    - name: string     #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
+      mountPath: string    #存储卷在容器内mount的绝对路径，应少于512字符
+      readOnly: boolean    #是否为只读模式
+    ports:       #需要暴露的端口库号列表
+    - name: string     #端口号名称
+      containerPort: int   #容器需要监听的端口号
+      hostPort: int    #容器所在主机需要监听的端口号，默认与Container相同
+      protocol: string     #端口协议，支持TCP和UDP，默认TCP
+    env:       #容器运行前需设置的环境变量列表
+    - name: string     #环境变量名称
+      value: string    #环境变量的值
+    resources:       #资源限制和请求的设置
+      limits:      #资源限制的设置
+        cpu: string    #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
+        memory: string     #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
+      requests:      #资源请求的设置
+        cpu: string    #Cpu请求，容器启动的初始可用数量
+        memory: string     #内存清楚，容器启动的初始可用数量
+    livenessProbe:     #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可
+      exec:      #对Pod容器内检查方式设置为exec方式
+        command: [string]  #exec方式需要制定的命令或脚本
+      httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
+        path: string
+        port: number
+        host: string
+        scheme: string
+        HttpHeaders:
+        - name: string
+          value: string
+      tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式
+         port: number
+       initialDelaySeconds: 0  #容器启动完成后首次探测的时间，单位为秒
+       timeoutSeconds: 0   #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
+       periodSeconds: 0    #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
+       successThreshold: 0
+       failureThreshold: 0
+       securityContext:
+         privileged:false
+    restartPolicy: [Always | Never | OnFailure]#Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod
+    nodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定
+    imagePullSecrets:    #Pull镜像时使用的secret名称，以key：secretkey格式指定
+    - name: string
+    hostNetwork:false      #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
+    volumes:       #在该pod上定义共享存储卷列表
+    - name: string     #共享存储卷名称 （volumes类型有很多种）
+      emptyDir: {}     #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
+      hostPath: string     #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
+        path: string     #Pod所在宿主机的目录，将被用于同期中mount的目录
+      secret:      #类型为secret的存储卷，挂载集群与定义的secre对象到容器内部
+        scretname: string
+        items:
+        - key: string
+          path: string
+      configMap:     #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
+        name: string
+        items:
+        - key: string
+```
+
+### 实例文件
+
+```
+apiVersion: extensions/v1beta1   #接口版本
+kind: Deployment                 #接口类型
+metadata:
+  name: ptengine-demo               #Deployment名称
+  namespace: ptengine-prd           #namespace 名称
+  labels:
+    app: ptengine-demo              #标签
+spec:
+  replicas: 3
+   strategy:
+    rollingUpdate:  ##由于replicas为3,则整个升级,pod个数在2-4个之间
+      maxSurge: 1       #滚动升级时会先启动1个pod
+      maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
+  template:
+    metadata:
+      labels:
+        app: ptengine-demo  #模板名称必填
+    sepc: #定义容器模板，该模板可以包含多个容器
+      containers:
+        - name: ptengine-demo                                                           #镜像名称
+          image: reg.pt1.com/ptengine-prd/ptengine-demo:0.0.1-SNAPSHOT #镜像地址
+          CMD: [ "/bin/sh","-c","cat /etc/config/path/to/special-key" ]    #启动CMD
+          args:                                                                #启动参数
+            - '-storage.local.retention=$(STORAGE_RETENTION)'
+            - '-web.external-url=$(EXTERNAL_URL)'
+
+          imagePullPolicy: IfNotPresent  #如果不存在则拉取
+          livenessProbe:       #表示container是否处于live状态。如果LivenessProbe失败，LivenessProbe将会通知kubelet对应的container不健康了。随后kubelet将kill掉container，并根据RestarPolicy进行进一步的操作。默认情况下LivenessProbe在第一次检测之前初始化值为Success，如果container没有提供LivenessProbe，则也认为是Success；
+            httpGet:
+              path: /health #如果没有心跳检测接口就为/
+              port: 8080
+              scheme: HTTP
+            initialDelaySeconds: 60 ##启动后延时多久开始运行检测
+            timeoutSeconds: 5
+            successThreshold: 1
+            failureThreshold: 5
+            readinessProbe:
+          readinessProbe:
+            httpGet:
+              path: /health #如果没有健康检测接口就为/
+              port: 8080
+              scheme: HTTP
+            initialDelaySeconds: 30 ##启动后延时多久开始运行检测
+            timeoutSeconds: 5
+            successThreshold: 1
+            failureThreshold: 5
+          resources:              ##CPU内存限制
+            requests:
+              cpu: 2
+              memory: 2048Mi
+            limits:
+              cpu: 2
+              memory: 2048Mi
+          env:                    ##通过环境变量的方式，直接传递pod=自定义Linux OS环境变量
+            - name: LOCAL_KEY     #本地Key
+              value: value
+            - name: CONFIG_MAP_KEY  #local策略可使用configMap的配置Key，
+              valueFrom:
+                configMapKeyRef:
+                  name: special-config   #configmap中找到name为special-config
+                  key: special.type      #找到name为special-config里data下的key
+          ports:
+            - name: http
+              containerPort: 8080 #对service暴露端口
+          volumeMounts:     #挂载volumes中定义的磁盘
+          - name: log-cache
+            mount: /tmp/log
+          - name: sdb       #普通用法，该卷跟随容器销毁，挂载一个目录
+            mountPath: /data/media
+          - name: nfs-client-root    #直接挂载硬盘方法，如挂载下面的nfs目录到/mnt/nfs
+            mountPath: /mnt/nfs
+          - name: example-volume-config  #高级用法第1种，将ConfigMap的log-script,backup-script分别挂载到/etc/config目录下的一个相对路径path/to/...下，如果存在同名文件，直接覆盖。
+            mountPath: /etc/config
+          - name: rbd-pvc                #高级用法第2中，挂载PVC(PresistentVolumeClaim)
+
+#使用volume将ConfigMap作为文件或目录直接挂载，其中每一个key-value键值对都会生成一个文件，key为文件名，value为内容，
+  volumes:  # 定义磁盘给上面volumeMounts挂载
+  - name: log-cache
+    emptyDir: {}
+  - name: sdb  #挂载宿主机上面的目录
+    hostPath:
+      path: /any/path/it/will/be/replaced
+  - name: example-volume-config  # 供ConfigMap文件内容到指定路径使用
+    configMap:
+      name: example-volume-config  #ConfigMap中名称
+      items:
+      - key: log-script           #ConfigMap中的Key
+        path: path/to/log-script  #指定目录下的一个相对路径path/to/log-script
+      - key: backup-script        #ConfigMap中的Key
+        path: path/to/backup-script  #指定目录下的一个相对路径path/to/backup-script
+  - name: nfs-client-root         #供挂载NFS存储类型
+    nfs:
+      server: 10.42.0.55          #NFS服务器地址
+      path: /opt/public           #showmount -e 看一下路径
+  - name: rbd-pvc                 #挂载PVC磁盘
+    persistentVolumeClaim:
+      claimName: rbd-pvc1         #挂载已经申请的pvc磁盘
+```
+
+## 参考文档
+- [Kubernetes 笔记 05 yaml 配置文件详解](https://www.cnblogs.com/bakari/p/10509484.html)
+- [详解Kubernetes Deployment的描述文件及相关配置](https://my.oschina.net/gibsonxue/blog/1840887)
+

content.md

@@ -0,0 +1,60 @@
+
+# 内容
+
+- [5G](5g.md)
+- [AOP & IOC](AOP.md)
+- [Tesla Corporate Culture](CorporateCulture.md)
+- [护网行动](HW.md)
+- [DevOps](README.md)
+- [backup](backup.md)
+- [开发模式](branch_mode.md)
+- [认证培训](certificates.md)
+- [云宽带分享](cloudbroadband.md)
+- [云原生](cloudnative.md)
+- [PMP理念](pmpcore.md)
+- [cmder](cmder.md)
+- [编译](compile.md)
+- [K8S yaml文件详解](config_k8s.md)
+- [数据库](database.md)
+- [DBA](dba.md)
+- [第一篇：K8S三种部署策略](deployment.md)
+- [第二篇：K8S基于ingress-nginx实现灰度发布](deployment.md)
+- [正确理解DevOps开发运维一体化](devops.md)
+- [devops master certificate](devopscertificate.md)
+- [devops master certificate](devopsmaster证书.md)
+- [devops master summary](devopssummary.md)
+- [devops测试](devopstest.md)
+- [DevOps/CD/CI题目](devopstest_v2.md)
+- [容灾](disaster_recovery.md)
+- [对传统应用进行容器化改造](dock_trans.md)
+- [docker](docker.md)
+- [信息安全校园招聘](ip_safe.md)
+- [王登开工作交接](jiaojie.md)
+- [Kubernetes介绍](k8slearning.md)
+- [kubectl基本使用](kubectl.md)
+- [本页列举了常用的 “kubectl” 命令和标志](kubectlcmd.md)
+- [Kubernetes](kubernetes.md)
+- [编程思考](language.md)
+- [lean / 精益](lean.md)
+- [mall-swarm容器化实践](mall_swarm_practic.md)
+- [This is an tag](mdlab.md)
+- [监控技术](monitor.md)
+- [消息系统](mq.md)
+- [运维知识体系](opsknowledge.md)
+- [自动化运维平台](platform.md)
+- [信息安全体系](security.md)
+- [上线规范](shangxian.md)
+- [SLA (Service-Level Agreement) 服务等级协议](sla.md)
+- [google SRE](sre.md)
+- [防篡改](tamper_proof.md)
+- [tools](tools.md)
+- [精益 & TPS](tps.md)
+- [云原生环境下安全运维分享](training.md)
+- [中台-自动化巡检](xunjian.md)
+- [管理](guanli.md)
+- [创新课题](chuangxin.md)
+- [分布式架构](fengbushi.md)
+- [AIOps](aiops.md)
+
+2018-11-1
+

curlweb.md

@@ -0,0 +1,5 @@
+
+
+for ((i=1; i<=1000; i++)) do curl -klvg "http://180.101.49.12:443"; sleep 0.1; done;
+for ((i=1; ; i++)) { curl -klvg "http://180.101.49.12:443"; sleep 0.1; }
+

database.md

@@ -0,0 +1,76 @@
+# 数据库
+
+```
+KISS - Keep It Simple & Stupid；
+```
+
+数据被快速制造和消费，数据看上去更加无秩序，或叫非结构化，据说超过80%，且持续加速增加，于是新的非关系型DB/noSQL快速崛起
+
+
+#### :question:
+- 类型
+- 特点
+- 选型
+
+
+#### 数据库类型
+```
+- Relational DBMS
+  - oracle,mysql,postgreSQL,hive
+- Key-value stores
+  - redis,memcached
+- Document stores/document-oriented database
+- Graph DBMS
+  - neo4j,Microsoft Azure Cosmos DB
+- Time Series DBMS
+  - InfluxDB,Kdb+,Prometheus,Graphite,RRDtool,OpenTSDB,Druid
+- Object oriented DBMS
+- RDF stores
+- Search engines
+  - Elasticsearch,Splunk
+- Wide column stores
+ - Cassandra,hbase
+- Multivalue DBMS
+- Native XML DBMS
+- Event Stores
+- Content stores
+- Navigational DBMS
+```
+
+#### Document stores database
+also called document-oriented database systems, are characterized by their schema-free organization of data.
+Records do not need to have a uniform structure, i.e. different records may have different columns.
+The types of the values a€?a€?of individual columns can be different for each record.
+Columns can have more than one value (arrays).
+Records can have a nested structure.
+Document stores often use internal notations, which can be processed directly in applications, mostly JSON. 
+JSON documents of course can also be stored as pure text in key-value stores or relational database systems. 
+That would, however, require client-side processing of the structures, which has the disadvantage that the features offered by document stores (such as secondary indexes) are not available.
+<br>存储文档数据库，也叫面向文档数据库，主要特点是非结构化、数据的自由组织
+纪录可以非结构化，比如不同纪录中的可以有不同的列，不同列的数据类型也可以不同，列的数据可以是多个值，比如一个array，记录还可以是嵌套结构。
+比如方便直接存储JSON数据，key-value数据库也可以存储JSON数据，但客户需要自己处理数据结构，这样就容易失去JSON数据组织的优点，比如第二个索引
+
+#### kafka & redis
+
+## 消息系统
+:question:
+- 异步
+- 解耦
+- 顺序
+
+kafka通过zookeeper来存储集群的meta信息
+
+[Redis哨兵模式（sentinel）学习总结及部署记录（主从复制、读写分离、主从切换）](https://www.cnblogs.com/kevingrace/p/9004460.html)
+
+
+
+![db trend](imgs/db/dbtrend.png)
+![db trend 24 months](imgs/db/dbtrend24m.png)
+
+
+
+#### references
+1. [db ranking](https://db-engines.com/en/ranking)
+1. [influxDB vs. openTSDB](http://blog.fatedier.com/2016/07/06/test-influxdb-and-opentsdb/)
+1. [openTSDB](http://blog.fatedier.com/2016/07/04/research-of-time-series-database-opentsdb/)
+1. [恒丰银行——大数据实时流处理平台](http://www.sohu.com/a/148106853_400678)

dba.md

@@ -0,0 +1,21 @@
+
+# DBA
+
+- 结对
+
+- 数据库性能
+  - 大规模数据，分表/分库、集群
+
+- 数据库故障排查
+  - 备份、容灾、演练
+
+- 数据安全
+  - 数据完整性
+  - 安全漏洞
+
+- 数据库监控
+
+- 升级/回滚
+
+- 数据库设计/架构的建议、优化
+

dbmiddleware.md

@@ -0,0 +1,34 @@
+## 数据库中间件
+
+:question:
+- 读写分离，&效率
+- 分库分表，切分能力
+- HA能力
+- 并发性
+- 稳定性
+- 可维护性
+- 社区活跃度，开源持续维护
+
+* [myCat note](mycat.md)
+
+Mycat与以上中间件的对比如下表所示。
+对比项目|[mycat](https://github.com/MyCATApache/Mycat-doc)|Mango|Cobar|Heisenberg|[Atlas](https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md)|Amoeba
+
+| mycat | cobar | Atlas | TDDL | heisenberg | Oceanus | vitess | OneProxy |
+| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
+| 公司 | 阿里 |  | 阿里 | 百度 | 360 |  |  |
+| 数据切片 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 |  |
+| 读写分离 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 |  |
+| 宕机自动切换 | 支持 | 不支持 | 支持 | 不支持 | 半支持，影响写 | 不支持 |  |
+| MySQL协议 | 前后端支持 | JDBC | 前端支持 | 前后端支持 | 前后端支持 | JDBC |  |
+| 支持的数据库 | MySQL、Oracle、MongoDB、PostgreSQL | MySQL | MySQL | MySQL | MySQL | MySQL、MongoDB |  |
+| 社区活跃度 | 高 | 活跃 | 停滞 | 低 | 中等 | 停滞 |  |
+| 文档资料 | 极丰富 | 较齐全 | 较齐全 | 缺少 | 中等 | 缺少 |  |
+| 是否开源 | 开源 | 开源 | 开源 | 开源 | 开源 | 开源 |  |
+| 是否支持事务 | 弱XA | 支持 | 单库强一致、分布式弱事务 | 单库强一致、多库弱事务 | 单库强一致、分布式弱事务 | 不支持 |  |
+
+DAL
+MySQL DAL（Data Access Layer）数据访问层
+
+分表：如UID mod 2分2张表存储，查询时同样操作
+

deployment.md

@@ -0,0 +1,949 @@
+
+Question:
+---
+```
+如何解决采用金丝雀部署时间代价的问题。
+场景：一个较大项目通过滚动部署正常大约需要1小时，重要服务的部署一般会放在凌晨开展，通过金丝雀部署，canary版本验证时间会串入总时间，版本验证时间如消耗1小时，那么意味着运维人员至少晚1个小时回家。
+
+所以，目前的做法是测试完的服务，滚动部署完成所有服务生产部署后，支撑人员做一个UAT，没问题结束，有问题回滚待下一次上线。
+
+=> 改进
+
+1. 自动化测试程度提高，canary版本可以通过自动化方式验证，从而节省测试串入时间。
+2. canary版本可以通过自动化一键验证（比如通过加header的方式让自动化测试验证匹配header value的canary版本），验证成功直接patch到旧版本，验证不成功，删除canary版本，相当于回滚，且不影响生产用户。
+3. header value ＋ weight 方式发布，可以让部分体验用户使用新功能，体验app？
+
+```
+
+# 第一篇：K8S三种部署策略
+
+## 1. 部署策略对比
+
+分别对滚动部署、蓝绿部署和金丝雀部署进行对比
+
+### 滚动部署
+应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。
+
+![Screenshot_2021-10-08-14-20-37-390_com.android.browser.png](https://i.loli.net/2021/10/08/FLNrvu5mTnYa7Cy.png)
+部署策略对比：滚动部署、蓝绿部署以及金丝雀部署
+
+### 蓝绿部署
+应用的新版本部署在绿色版本环境中，进行功能和性能测试。一旦测试通过，应用的流量从蓝色版本路由到绿色版本。然后绿色版本变成新的生产环境。在这个方法中，两个相同的生产环境并行工作。
+
+![Screenshot_2021-10-08-14-21-21-681_com.android.browser.png](https://i.loli.net/2021/10/08/p7h84u6AEDyxMl9.png)
+部署策略对比：滚动部署、蓝绿部署以及金丝雀部署
+
+![Screenshot_2021-10-08-14-21-31-176_com.android.browser.png](https://i.loli.net/2021/10/08/D5PmG3u4L2fIqS7.png)
+部署策略对比：滚动部署、蓝绿部署以及金丝雀部署
+
+### 金丝雀部署
+采用金丝雀部署，你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。如果没有错误发生，新版本可以逐渐推广到整个基础设施。以前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。下图示范了金丝雀部署：
+
+![Screenshot_2021-10-08-14-21-41-910_com.android.browser.png](https://i.loli.net/2021/10/08/shUZ6SaKfI5iWRF.png)
+部署策略对比：滚动部署、蓝绿部署以及金丝雀部署
+
+金丝雀部署包括将生产流量从版本A逐渐转移到版本B。通常，流量是根据权重分配的。 例如，90％的请求发送到版本A，10％的请求发送到版本B。
+
+## 2. 使用Kubernetes实现金丝雀部署
+
+主要步骤：
+1. 部署v1版本的应用，此时service访问的都是v1版本的服务
+2. 部署v2版本，数量为x/10，同时缩小v1版本的数量x/10，此时有x/10的流量到v2版本的服务
+3. 逐步缩小v1，扩大v2，最终v2版本替换全部的v1
+
+### 2.1 搭建模拟的服务
+
+app-v1.yaml : https://github.com/ContainerSolutions/k8s-deployment-strategies/blob/master/canary/native/app-v1.yaml
+
+```
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-app
+  labels:
+    app: my-app
+spec:
+  type: NodePort
+  ports:
+  - name: http
+    port: 80
+    targetPort: http
+  selector:
+    app: my-app
+```
+---
+```
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-app-v1
+  labels:
+    app: my-app
+spec:
+  replicas: 10
+  selector:
+    matchLabels:
+      app: my-app
+      version: v1.0.0
+  template:
+    metadata:
+      labels:
+        app: my-app
+        version: v1.0.0
+      annotations:
+        prometheus.io/scrape: "true"
+        prometheus.io/port: "9101"
+    spec:
+      containers:
+      - name: my-app
+        image: containersol/k8s-deployment-strategies
+        ports:
+        - name: http
+          containerPort: 8080
+        - name: probe
+          containerPort: 8086
+        env:
+        - name: VERSION
+          value: v1.0.0
+        livenessProbe:
+          httpGet:
+            path: /live
+            port: probe
+          initialDelaySeconds: 5
+          periodSeconds: 5
+        readinessProbe:
+          httpGet:
+            path: /ready
+            port: probe
+          periodSeconds: 5
+```
+
+$kubectl apply -f app-v1.yaml
+
+```
+service/my-app created
+deployment.apps/my-app-v1 created
+```
+
+$kubectl get service my-app
+
+```
+NAME     TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
+my-app   NodePort   10.98.198.198   <none>        80:30969/TCP   23m
+```
+
+$curl 10.98.198.198:80
+
+```
+Host: my-app-v1-c9b7f9985-5qvz4, Version: v1.0.0
+```
+
+### 2.2 应用使用金丝雀部署方式来升级
+接下来，我们对my-app-v1升级到my-app-v2：
+
+app-v2.yaml : https://github.com/ContainerSolutions/k8s-deployment-strategies/blob/master/canary/native/app-v2.yaml
+
+```
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-app-v2
+  labels:
+    app: my-app
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: my-app
+      version: v2.0.0
+  template:
+    metadata:
+      labels:
+        app: my-app
+        version: v2.0.0
+      annotations:
+        prometheus.io/scrape: "true"
+        prometheus.io/port: "9101"
+    spec:
+      containers:
+      - name: my-app
+        image: containersol/k8s-deployment-strategies
+        ports:
+        - name: http
+          containerPort: 8080
+        - name: probe
+          containerPort: 8086
+        env:
+        - name: VERSION
+          value: v2.0.0
+        livenessProbe:
+          httpGet:
+            path: /live
+            port: probe
+          initialDelaySeconds: 5
+          periodSeconds: 5
+        readinessProbe:
+          httpGet:
+            path: /ready
+            port: probe
+          periodSeconds: 5
+```
+
+开启watch来监控pod和deployment的变化
+
+$kubectl get --watch deployment
+
+$kubectl get --watch pod
+
+
+升级
+
+$kubectl apply -f app-v2.yaml
+
+```
+deployment.apps/my-app-v2 created
+```
+
+此时可以看到，my-app-v2启动了1个
+
+$kubectl get --watch deployment
+
+```
+NAME        READY   UP-TO-DATE   AVAILABLE   AGE
+my-app-v1   10/10   10           10          45m
+my-app-v2   1/1     1            1           46s
+```
+
+$kubectl scale --replicas=9 deploy my-app-v1
+
+```
+deployment.apps/my-app-v1 scaled
+```
+
+$kubectl get deployments
+
+```
+NAME        READY   UP-TO-DATE   AVAILABLE   AGE
+my-app-v1   9/9     9            9           47m
+my-app-v2   1/1     1            1           2m48s
+```
+
+此时，我们将my-app-v1 缩小到9个，这样通过service的负载均衡，my-app-v2会承接到%10（1/20）的流量
+
+```
+$service=10.98.198.198:80
+
+$while sleep 0.1; do curl "$service"; done
+
+Host: my-app-v1-c9b7f9985-mqnmr, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-bl4g7, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-rmng9, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-mz9hc, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-bl4g7, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-mz9hc, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-mm6fp, Version: v1.0.0
+Host: my-app-v2-77fc8c9499-m6n9j, Version: v2.0.0
+Host: my-app-v1-c9b7f9985-l69pf, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-mqnmr, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-mz9hc, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-62zb4, Version: v1.0.0
+```
+
+验证通过后，我们逐步将my-app-v2扩容到10个，将my-app-v1缩小到0个
+
+$kubectl scale --replicas=10 deploy my-app-v2
+
+$kubectl delete deploy my-app-v1
+
+再次验证服务，会发现my-app-v2承接了所有流量:
+
+```
+$while sleep 0.1; do curl "$service"; done
+```
+
+测试完成清理数据
+
+$kubectl delete all -l app=my-app
+
+## 3. 使用Kubernetes实现蓝绿部署
+
+主要步骤：
+1. 部署v1版本 ，此时service访问的都是v1版本的服务
+2. 部署v2版本，直到部署完成
+3. 将service的流量从v1版本切换到v2版本
+4. 销毁v1
+
+首先，通过如下命令监控pod的实时状态
+
+$watch kubectl get pod
+
+### 3.1 搭建模拟的服务
+app-v1.yaml:https://github.com/ContainerSolutions/k8s-deployment-strategies/blob/master/blue-green/single-service/app-v1.yaml
+
+```
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-app
+  labels:
+    app: my-app
+spec:
+  type: NodePort
+  ports:
+  - name: http
+    port: 80
+    targetPort: http
+
+  # Note here that we match both the app and the version
+  selector:
+    app: my-app
+    version: v1.0.0
+```
+---
+```
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-app-v1
+  labels:
+    app: my-app
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: my-app
+      version: v1.0.0
+  template:
+    metadata:
+      labels:
+        app: my-app
+        version: v1.0.0
+      annotations:
+        prometheus.io/scrape: "true"
+        prometheus.io/port: "9101"
+    spec:
+      containers:
+      - name: my-app
+        image: containersol/k8s-deployment-strategies
+        ports:
+        - name: http
+          containerPort: 8080
+        - name: probe
+          containerPort: 8086
+        env:
+        - name: VERSION
+          value: v1.0.0
+        livenessProbe:
+          httpGet:
+            path: /live
+            port: probe
+          initialDelaySeconds: 5
+          periodSeconds: 5
+        readinessProbe:
+          httpGet:
+            path: /ready
+            port: probe
+          periodSeconds: 5
+```
+部署服务和v1版本
+
+$kubectl apply -f app-v1.yaml
+
+```
+service/my-app created
+deployment.apps/my-app-v1 created
+```
+
+$kubectl get service
+
+```
+NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
+kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        14d
+my-app       NodePort    10.111.231.242   <none>        80:31540/TCP   18s
+```
+
+$while sleep 0.1;do curl 10.111.231.242:80;done
+
+```
+Host: my-app-v1-c9b7f9985-wqpf5, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-wqpf5, Version: v1.0.0
+Host: my-app-v1-c9b7f9985-gnhr4, Version: v1.0.0
+```
+
+### 3.2 部署v2版本
+
+app-v2.yaml:https://github.com/ContainerSolutions/k8s-deployment-strategies/blob/master/blue-green/single-service/app-v2.yaml
+
+```
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-app-v2
+  labels:
+    app: my-app
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: my-app
+      version: v2.0.0
+  template:
+    metadata:
+      labels:
+        app: my-app
+        version: v2.0.0
+      annotations:
+        prometheus.io/scrape: "true"
+        prometheus.io/port: "9101"
+    spec:
+      containers:
+      - name: my-app
+        image: containersol/k8s-deployment-strategies
+        ports:
+        - name: http
+          containerPort: 8080
+        - name: probe
+          containerPort: 8086
+        env:
+        - name: VERSION
+          value: v2.0.0
+        livenessProbe:
+          httpGet:
+            path: /live
+            port: probe
+          initialDelaySeconds: 5
+          periodSeconds: 5
+        readinessProbe:
+          httpGet:
+            path: /ready
+            port: probe
+          periodSeconds: 5
+```
+
+部署完成后，我们可以看到，总共个部署了两个版本的deployment。有3个pod是v1，另外3个是v2的。而当前service访问的都是v1版本的服务
+
+![Screenshot_2021-10-08-14-22-30-848_com.android.browser.png](https://i.loli.net/2021/10/08/5f7Qzk28NhlWm6L.png)
+image.png
+接下来，就是要将服务的流量切到v2
+
+$kubectl patch service my-app -p '{"spec":{"selector":{"version":"v2.0.0"}}}'
+
+此时可以看到，服务的流量都到了v2
+
+![Screenshot_2021-10-08-14-22-48-523_com.android.browser.png](https://i.loli.net/2021/10/08/LZQ2cqFz8mV9aiA.png)
+image.png
+验证没问题后，我们把v1删除
+
+$kubectl delete deploy my-app-v1
+
+若有问题，可以回滚
+
+$kubectl patch service my-app -p '{"spec":{"selector":{"version":"v1.0.0"}}}'
+
+## 4. 使用Kubernetes实现滚动部署
+
+主要步骤：
+1. 部署v1版本 ，此时service访问的都是v1版本的服务
+2. 设置v2版本，且更新策略为滚动更新
+3. 部署v2版本
+
+### 4.1 搭建模拟的服务
+
+app-v1.yaml: https://github.com/ContainerSolutions/k8s-deployment-strategies/blob/master/ramped/app-v1.yaml
+
+```
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-app
+  labels:
+    app: my-app
+spec:
+  type: NodePort
+  ports:
+  - name: http
+    port: 80
+    targetPort: http
+  selector:
+    app: my-app
+```
+---
+```
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-app
+  labels:
+    app: my-app
+spec:
+  replicas: 10
+  selector:
+    matchLabels:
+      app: my-app
+  template:
+    metadata:
+      labels:
+        app: my-app
+        version: v1.0.0
+      annotations:
+        prometheus.io/scrape: "true"
+        prometheus.io/port: "9101"
+    spec:
+      containers:
+      - name: my-app
+        image: containersol/k8s-deployment-strategies
+        ports:
+        - name: http
+          containerPort: 8080
+        - name: probe
+          containerPort: 8086
+        env:
+        - name: VERSION
+          value: v1.0.0
+        livenessProbe:
+          httpGet:
+            path: /live
+            port: probe
+          initialDelaySeconds: 5
+          periodSeconds: 5
+        readinessProbe:
+          httpGet:
+            path: /ready
+            port: probe
+          periodSeconds: 5
+```
+
+部署app-v1.yaml
+
+$kubectl apply -f app-v1.yaml
+
+```
+service/my-app created
+deployment.apps/my-app created
+```
+
+$kubectl get service
+
+```
+NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
+kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP        14d
+my-app       NodePort    10.100.43.22   <none>        80:32725/TCP   45s
+```
+
+$curl 10.100.43.22:80
+
+```
+Host: my-app-c9b7f9985-ph2fz, Version: v1.0.0
+```
+
+### 4.2 接下来准备进行滚动升级
+
+通过如下命令监控pod的变化
+
+$watch kubectl get pod
+
+app-v2.yaml : https://github.com/ContainerSolutions/k8s-deployment-strategies/blob/master/ramped/app-v2.yaml
+
+```
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-app
+  labels:
+    app: my-app
+spec:
+  replicas: 10
+
+  # Here we define the rolling update strategy
+  # - maxSurge define how many pod we can add at a time
+  # - maxUnavailable define how many pod can be unavailable
+  #   during the rolling update
+  #
+  # Setting maxUnavailable to 0 would make sure we have the appropriate
+  # capacity during the rolling update.
+  # You can also use percentage based value instead of integer.
+  strategy:
+    type: RollingUpdate
+    rollingUpdate:
+      maxSurge: 1
+      maxUnavailable: 0
+
+  # The selector field tell the deployment which pod to update with
+  # the new version. This field is optional, but if you have labels
+  # uniquely defined for the pod, in this case the "version" label,
+  # then we need to redefine the matchLabels and eliminate the version
+  # field from there.
+  selector:
+    matchLabels:
+      app: my-app
+  template:
+    metadata:
+      labels:
+        app: my-app
+        version: v2.0.0
+      annotations:
+        prometheus.io/scrape: "true"
+        prometheus.io/port: "9101"
+    spec:
+      containers:
+      - name: my-app
+        image: containersol/k8s-deployment-strategies
+        ports:
+        - name: http
+          containerPort: 8080
+        - name: probe
+          containerPort: 8086
+        env:
+        - name: VERSION
+          value: v2.0.0
+        livenessProbe:
+          httpGet:
+            path: /live
+            port: probe
+          initialDelaySeconds: 5
+          periodSeconds: 5
+        readinessProbe:
+          httpGet:
+            path: /ready
+            port: probe
+
+          # Intial delay is set to a high value to have a better
+          # visibility of the ramped deployment
+          initialDelaySeconds: 15
+          periodSeconds: 5
+```
+
+开始升级
+
+$kubectl apply -f app-v2.yaml
+
+```
+deployment.apps/my-app configured
+```
+
+同时可以看到pod正在被逐步替换
+
+![Screenshot_2021-10-08-14-23-08-551_com.android.browser.png](https://i.loli.net/2021/10/08/NqISZGDowdzv5CK.png)
+image.png
+在逐步替换的过程中，为了验证流量，可以随时暂停升级，暂停恢复命令如下
+
+$kubectl rollout pause deploy my-app
+
+```
+deployment.apps/my-app paused
+```
+
+$kubectl rollout resume deploy my-app
+
+```
+deployment.apps/my-app resumed
+```
+
+
+# 第二篇：K8S基于ingress-nginx实现灰度发布
+
+之前介绍过使用ambassador实现灰度发布，今天介绍如何使用ingre-nginx实现。
+
+## 介绍
+
+Ingress-Nginx 是一个K8S ingress工具，支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试。
+
+Nginx Annotations 支持以下 4 种 Canary 规则：
+
+### nginx.ingress.kubernetes.io/canary-by-header：
+基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never时，请求不会被发送到 Canary 入口；对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。
+
+### nginx.ingress.kubernetes.io/canary-by-header-value：
+要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (即：canary-by-header）一起使用。
+
+### nginx.ingress.kubernetes.io/canary-weight：
+基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为 100 意味着所有请求都将被发送到 Canary 入口。
+
+### nginx.ingress.kubernetes.io/canary-by-cookie：
+基于 Cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always时，它将被路由到 Canary 入口；当 cookie 值设置为 never时，请求不会被发送到 Canary 入口；对于任何其他值，将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。
+
+
+注意：金丝雀规则按优先顺序进行如下排序：
+
+canary-by-header - > canary-by-cookie - > canary-weight
+
+我们可以把以上的四个 annotation 规则可以总体划分为以下两类：
+
+基于权重的 Canary 规则
+![658e7d2fb7c671f4.png](https://i.loli.net/2021/10/08/C8kiKuO7a1T6mtI.png)
+
+基于用户请求的 Canary 规则
+![d1899062bab4dc0f.png](https://i.loli.net/2021/10/08/iUu7fCacj4XLGgA.png)
+
+注意： Ingress-Nginx 实在0.21.0 版本 中，引入的Canary 功能，因此要确保ingress版本OK
+
+## 测试
+
+### 应用准备
+两个版本的服务，正常版本：
+
+```
+import static java.util.Collections.singletonMap;
+
+@SpringBootApplication
+@Controller
+public class RestPrometheusApplication {
+
+	@Autowired
+	private MeterRegistry registry;
+
+	@GetMapping(path = "/", produces = "application/json")
+	@ResponseBody
+	public Map<String, Object> landingPage() {
+		Counter.builder("mymetric").tag("foo", "bar").register(registry).increment();
+		return singletonMap("hello", "ambassador");
+	}
+
+	public static void main(String[] args) {
+		SpringApplication.run(RestPrometheusApplication.class, args);
+	}
+}
+```
+
+访问会输出：
+
+```
+{"hello":"ambassador"}
+```
+灰度版本：
+
+```
+import static java.util.Collections.singletonMap;
+
+@SpringBootApplication
+@Controller
+public class RestPrometheusApplication {
+
+	@Autowired
+	private MeterRegistry registry;
+
+	@GetMapping(path = "/", produces = "application/json")
+	@ResponseBody
+	public Map<String, Object> landingPage() {
+		Counter.builder("mymetric").tag("foo", "bar").register(registry).increment();
+		return singletonMap("hello", "ambassador, this is a gray version");
+	}
+
+	public static void main(String[] args) {
+		SpringApplication.run(RestPrometheusApplication.class, args);
+	}
+
+}
+```
+
+访问会输出：
+
+```
+{"hello":"ambassador, this is a gray version"}
+```
+
+### ingress 配置
+
+#### header
+我们部署好两个服务，springboot-rest-demo是正常的服务，springboot-rest-demo-gray是灰度服务，我们来配置ingress，通过canary-by-header来实现：
+
+正常服务的：
+
+```
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  name: springboot-rest-demo
+  annotations:
+    kubernetes.io/ingress.class: nginx
+spec:
+  rules:
+  - host: springboot-rest.jadepeng.com
+    http:
+      paths:
+      - backend:
+          serviceName: springboot-rest-demo
+          servicePort: 80
+```
+canary 的：
+
+```
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  name: springboot-rest-demo-gray
+  annotations:
+    kubernetes.io/ingress.class: nginx
+    nginx.ingress.kubernetes.io/canary: "true"
+    nginx.ingress.kubernetes.io/canary-by-header: "canary"
+	nginx.ingress.kubernetes.io/canary-by-header-value: "true"
+spec:
+  rules:
+  - host: springboot-rest.jadepeng.com
+    http:
+      paths:
+      - backend:
+          serviceName: springboot-rest-demo-gray
+          servicePort: 80
+```
+将上面的文件执行：
+
+```
+kubectl -n=default apply -f ingress-test.yml
+ingress.extensions/springboot-rest-demo created
+ingress.extensions/springboot-rest-demo-gray created
+```
+
+执行测试，不添加header，访问的默认是正式版本：
+
+```
+$ curl http://springboot-rest.jadepeng.com; echo
+{"hello":"ambassador"}
+
+$ curl http://springboot-rest.jadepeng.com; echo
+{"hello":"ambassador"}
+```
+
+添加header，可以看到，访问的已经是灰度版本了
+
+```
+$ curl -H "canary: true" http://springboot-rest.jadepeng.com; echo
+{"hello":"ambassador, this is a gray version"}
+```
+
+#### weight
+
+```
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  annotations:
+    kubernetes.io/ingress.class: nginx
+    nginx.ingress.kubernetes.io/canary: "true"
+    nginx.ingress.kubernetes.io/canary-weight: "50"
+  name: helloworld-weight
+spec:
+  rules:
+  - host: hello.world.test
+    http:
+      paths:
+      - backend:
+          serviceName: hello-world-svc-v2
+          servicePort: 80
+```
+
+创建Ingress规则：
+
+```
+[root@vm10-0-11-201 ~]# kubectl apply -f helloworld-ingress.yaml
+ingress.extensions/hello-world created
+[root@vm10-0-11-201 ~]# kubectl apply -f weight-ingress.yaml
+ingress.extensions/helloworld-weight created
+[root@vm10-0-11-201 ~]# kubectl get ingress
+NAME                CLASS    HOSTS              ADDRESS   PORTS   AGE
+hello-world         <none>   hello.world.test             80      41s
+helloworld-weight   <none>   hello.world.test             80      27s
+```
+
+验证访问情况
+通过以下命令获取EXTERNAL-IP及访问服务：
+
+```
+[root@vm10-0-11-201 ~]# kubectl get svc -n ingress-nginx
+NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
+nginx-ingress   LoadBalancer   10.254.28.54   120.92.xx.xx   80:31741/TCP,443:32754/TCP   3h19m
+[root@vm10-0-11-201 ~]# for i in $(seq 1 10); do curl -H "Host: hello.world.test"  http://120.92.xx.xx; done;
+Hello World v2!
+Hello World v2!
+Hello World v1!
+Hello World v2!
+Hello World v2!
+Hello World v1!
+Hello World v1!
+Hello World v1!
+Hello World v2!
+Hello World v2!
+```
+多次访问能发现约50%的流量会被分发到v2版本服务中。
+
+#### others
+
+ingress-nginx 从 0.21.0 开始支持金丝雀（canary）模式，对应的 merge 是 3341。 Canary deploys with ingress-nginx 介绍了用法。
+
+首先创建一个普通的 ingress A 指向 Service A：
+
+```
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  annotations:
+    nginx.ingress.kubernetes.io/ingress.class: nginx
+    nginx.ingress.kubernetes.io/upstream-fail-timeout: "10"
+    nginx.ingress.kubernetes.io/upstream-max-fails: "2"
+  name: demo-echo-ingress
+  namespace: demo-echo
+spec:
+  rules:
+  - host: demo.echo.test
+    http:
+      paths:
+      - path: /
+        backend:
+          serviceName: webshell
+          servicePort: 80
+```
+然后创建一个设置了相同 host 和 path 的 ingress B，Ingress B 指向了另一个服务 Service B，并且在 annotations 中注明这是一个 canary ingress：
+
+```
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  annotations:
+    nginx.ingress.kubernetes.io/canary: "true"
+    nginx.ingress.kubernetes.io/canary-by-header: "version"
+    nginx.ingress.kubernetes.io/canary-by-header-value: "canary"
+    nginx.ingress.kubernetes.io/canary-by-cookie: "canary-cookie"
+    nginx.ingress.kubernetes.io/canary-weight: "50"
+    nginx.ingress.kubernetes.io/ingress.class: nginx
+    nginx.ingress.kubernetes.io/upstream-fail-timeout: "10"
+    nginx.ingress.kubernetes.io/upstream-max-fails: "2"
+  name: demo-echo-ingress-canary
+  namespace: demo-echo
+spec:
+  rules:
+  - host: demo.echo.test
+    http:
+      paths:
+      - path: /
+        backend:
+          serviceName: echo
+          servicePort: 80
+```
+带有 “version: canary” 头的请求都被发送到 canary 版本：
+
+```
+curl -H "version: canary" -H "Host: demo.echo.test" 10.10.64.58
+```
+相关参数为：
+
+```
+nginx.ingress.kubernetes.io/canary-by-header: "version"
+nginx.ingress.kubernetes.io/canary-by-header-value: "canary"
+```
+不带有 “version: canary” 头的请求一半被转发给 canary 版本，相关参数为：
+
+```
+nginx.ingress.kubernetes.io/canary-weight: "50"
+```
+还支持按照 cookie 选择，cookie 的值为 always 或者 never，前者转发给 canary，后者不转发，指定 cookie 名称的参数为 ：
+
+```
+nginx.ingress.kubernetes.io/canary-by-cookie: "canary-cookie"
+curl -v  -b canary-cookie=always demo.echo.test   # 访问金丝雀版本
+curl -v  -b canary-cookie=never demo.echo.test    # 访问非金丝雀版本
+header、cookie、weight 的作用顺序是：canary-by-header -> canary-by-cookie -> canary-weight。
+```
+
+## 参考
+https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary
+

devops.md

@@ -0,0 +1,68 @@
+
+# [正确理解DevOps开发运维一体化](https://www.aisoutu.com/a/67821)
+
+发布于 2020-12-25 00:20
+
+我们一直说DevOps是“谁开发谁运维、开发运维一体化”，但具体怎么做并没有几个人说的清楚的。特别是“谁开发谁运维”，这明显是不符合实际情况的。试想一下，一个开发人员开发的应用服务都由他自己来运维，他能运维几个应用服务？然后又有多少时间能继续做开发？到最后岂不是所有开发人员都成了运维人员。有点极端，但是也正说明了我们对DevOps的认识存在很大的误解。
+
+DevOps提倡“开发运维一体化”，但不是“谁开发谁运维”。但怎么开发运维一体化往往也都没有说清楚，也没有很好的实践案例。**Google SRE更多的其实是运维阶段的工作，虽然Google SRE很多工作是运维工具和运维服务的开发工作，但其本质上是做运维。但是它给我们的一个很好的启示是，把“运维开发”和“运维维护”一体化了，也就是运维人员不再是简单的系统管理和维护，而是通过运维工具的研发，使运维流程自动化和智能化，将一些日常重复性的运维工作通过自研工具自动化和智能化了，这就大大减轻了运维人员的维护工作量，提升了运维效率。**这些工作不再靠“研发人员”，而是“运维自身”的能力来实现的。
+
+CG: 
+*运维&开发不是一个工种门类，如何一体？如何粘合，不是说开发既做开发有做运维，这样无法专注开发，也无法专注运维，不是说运维和开发是一个人或一个团队，而是开发和运维能无缝衔接，形成反馈合力。那么如何做到这点，一是运维过程必须向前看，加速反馈和处理过程；二是必须依靠自动化工具，人的协作毕竟是非常重要的，但人存在效率偏差和技能偏差，单依靠人的协作，必然会在两者之间形成Gap，自动化工具形成管道，正式弥合这个gap，把两者粘合起来。*
+**优化原则：减少大量的人工沟通协同，而是应该通过工具链协同。**
+- 流水线增加启动检查节点，2个小时内有代码check in 则触发。
+- 是否需要人工验证，可以按commit desc 确认。
+- 需求和缺陷的管理
+- 需求和缺陷状态的变化
+- 变更驱动的版本开发和流水线设计
+
+DevOps开发运维一体化并不是让开发去做运维，而是使开发和运维通过一些机制有机结合、高效统一，成为一个整体，从而消除开发团队和运维团队之间的gap，有效提升应用服务的研发和运维运营效率。
+
+那么通过什么样的机制，如何来消除开发和运维之间的利益冲突，如何提升效率是我们在实施DevOps之前或者实施过程中需要认真思考的问题。
+
+Google SRE实践给我们了很好的运维阶段的DevOps实施启示。**运维还是需要专职做运维，而且比传统运维做的更多。**运维人员需要对自己运维的环境、工具、流程、资源等有深入的理解和认识，能独立开发运维工具，独立实现运维的自动化、智能化、高可用、稳定性、安全性等要求。支撑应用的运维和运营。这就使运维成为了一个有机的小闭环，包括了运维工具、流程等的需求、设计、开发、测试、部署、运营、反馈、改进等完整生命周期过程。这和业务应用的开发和运维运营是不同层次的。**SRE的工作在提升运维效率的同时也很好的支撑了业务应用的运维运营效率。**
+
+SRE侧重于DevOps的Ops运维阶段。DevOps的Dev开发阶段包括需求、设计、编码、测试、部署等过程。开发阶段则强调持续开发、持续部署或持续开发、持续交付，强调敏捷开发。目的还在于提高效率。环境的敏捷准备、环境的一致性是Dev阶段高效的重要基础。
+
+**传统开发、测试、UAT等环境都是由开发人员自己来维护。这也导致了往往和生产环境不一致，所以在生产部署时可能会存在很多意向不到的问题。因此在DevOps实践中，环境的运维一定要交由运维人员统一来维护，开发人员只是使用环境而不运维环境。**
+
+**谁有权限使用环境谁没有权限使用环境这又涉及到了DevOps中的统一权限管理和统一认证管理部分。**统一权限和认证管理可以作为企业的技术中台服务由技术中台运维团队来统一运维运营。为企业内外用户提供认证和权限服务。各个环境使用技术中台的统一认证权限平台的服务来完成认证和权限管控，也避免了重复的投入和建设。开发人员只需要用自己的账号随时登录不同的环境来完成自己的工作。这其实就是PaaS的理念。当然，你也可以在企业内部实现单点登录，一次登录，可以在拥有权限的不同环境之间切换来完成工作。这些是DevOps的基础工作。看似没有关系，却带来完全不同的效果。
+
+*CG: 开发、运维的权限边界在哪里？*
+
+**环境一致性可以简单的通过容器化来实现。**但容器环境只能达到相对一致性，并不能实现完全一致性。容器运行在不同配置的宿主机或虚拟化节点上，都会带来一定的差异。所以你也可能经常会遇到在某个节点性能很高，而某个时刻迁移到另外一个节点性能却不如预期。
+
+环境的敏捷准备则是一个相对不容易的工作。传统研发过程中通常很多时间都是花在环境准备上。不管是否采用容器化，这块的效率都是需要考虑提升的。在开发阶段涉及的流程和工作也比较多。比如开发环境准备、测试环境的准备、测试数据的准备、测试用例的自动构建、测试缺陷的自动记录等。而且这部分工作可以通过相应的工具实现敏捷能力，尽可能使工具和流程标准化，这样就可以实现自动化，就能更快的提升效率。
+
+*CG: alpha/beta 测试环境的准备谁负责？*
+
+而软件编码的标准化程度也相对就比较低，往往依赖于开发人员的个人能力和态度。软件研发其实质是智力投资，不同的人带来的效果完全是不一样的。**所以很多想以外包的方式实现自有软件的自主可控基本上是不现实的。**
+
+开发阶段最终需要交付标准化交付件，不管是容器镜像、或是jar、war、exe文件等，这些文件需要统一管理起来，镜像可以用镜像仓库，jar等可以通过配置管理工具等统一来管理，而部署则可以实现自动化，不管使用自动化脚本或者自动化工具，以减少部署问题和提升效率，支持**持续部署**的能力。
+
+我们在《容器云平台运维架构设计》也清楚地解释了开发和运维之间的标准化交付环节。这是减少开发和运维之间沟通成本和提升效率的重要机制。如果使用容器，镜像和镜像仓库将充当这样的一个标准化交付件和标准化交付管理媒介。它可以很好的划分和有效连接开发、测试、UAT、生产运维等应用生命周期阶段。
+
+另外我们知道DevOps很重要的是要形成闭环。运维运营对开发的反馈是非常重要的，不仅仅是bug和缺陷的反馈修复，包括用户体验等都是很重要的内容。这就需要合理合适的反馈机制和流程。既包括技术的，也包括非技术的因素。
+
+所以横向上我们可以简单的看作是开发、标准化交付和运维的划分，标准化交付就像是人的关节，起到润滑和弹性伸张的作用，使开发和运维成为一体并充分发挥各自的专业优势。而纵向上，可以通过分层来实现高度专业化运维。最下层是基础设施资源的运维，之上是平台、工具、环境的运维，在这些平台、工具、环境之上是业务应用的运维。所有这些工作都是为了保证业务运营的可用与安全。通过业务运营才能有收益、有利润。
+
+![1_16088294734824786.png](https://i.loli.net/2021/10/25/ujbVGPR71TpBqMO.png)
+
+从应用整个生命周期管理过程看，80%的基本工作可能是在运维阶段，运维的事项也比较多，从效率上讲，使各运维事项专业化、自动化甚至智能化则容易提升效率。开发运维一体化重点在于提升运维的效率，包括应用、环境、平台、工具、基础设施资源等。有高效、高可用的运维环节能力，则能保证业务应用的高可用与稳定性，也就是Google SRE的Site Reliabilities。而对于应用开发人员，即便是出现意外情况，运维也有应对措施，开发人员则有充足的时间进行细致的设计和问题处理，追求更稳定、可靠、高效的能力，从而使运维更容易和便利。
+
+开发运维一体化追求开发和运维的利益一致，而不是一个人既做开发也做运维。这需要通过一定的机制和借助相应的工具等来保证，使开发和运维之间能够有活动关节、有润滑剂。这应该是我们在构建DevOps的时候需要认真考虑实现的核心内容。
+
+
+
+## references
+- [猪八戒网DevOps容器云与流水线](http://dockone.io/article/8384)
+- [万达网络科技的DevOps平台架构解析](https://cloud.tencent.com/developer/article/1080141)
+- [DevOps之平台架构](https://www.cnblogs.com/cdani/p/7642386.html)
+- [流水线2.0驱动 CD/DevOps](https://cloud.tencent.com/developer/article/1035432)
+- [度量驱动的DevOps转型 ](https://www.sohu.com/a/124936190_468741)
+- [保障pipeline脚本在devops中成功应用的四大核心点](https://blog.csdn.net/liwenxiang629/article/details/120762790)
+- [DevOps能为倍增计划做点啥?](https://www.aisoutu.com/a/18920)
+- [高通量低延迟的云环境大数据流水线架构](https://www.infoq.cn/article/myKdXcvOtTTLtOmZTe3s?utm_source=rss&utm_medium=article)
+- [Devops 落地的核心和13条经验总结](http://info.dns110.com/321101.html)
+- []()
+

devops_blameless.md

@@ -0,0 +1,28 @@
+
+2020/3/3
+关于devops无问责文化
+
+故障分析会，讨论关于平台故障及应急流程是不是符合规范的问题，我们是这样，故障发生会对故障进行预判，如果是三级故障，即全局性最严重的的故障，那么就可以进行应急操作，目的是让业务可用，也就是“先抢通后修复”的原则。规范里对故障发生到应急事件，及故障修复时间有要求。
+
+因为刚刚领导对故障的处理不满意，之前也问责了几次，甚至也扣了绩效，所以，这个故障报告怎么写比较重视，在对过程统计进行分析中，我们发现这个处理的过程有人为迟滞，没有很好的理由加以说明。
+
+因为故障发生时有个处理小组实时沟通问题及处理过程，这时候就有人提出来，是不是可以建立一个新讨论组，把QA的人踢出去，这当然被我否决，我们要清楚故障总结的目的是什么！！！
+哈哈，这就是问责文化和质量警察最终的必然后果，因为这种文化下，我又怎能保证下次队员的这种“藏着掖着”手段不背着我进行呢。
+
+blame ： 问题发生 -> 甩锅，瞒报 -> 信息、特别是问题不透明 -> 原因不明 -> 问题积累 -> 欠债，集中爆发，各扫门前雪，官僚文化
+
+blameless ：问题发生 -> 反馈 -> 解决 -> 总结 -> 提升，非常符合PDCA环精益的方法论啊
+
+devops之所以强调blameless，因为blameless的确是基础，不光是让问题简单化，让团队更积极（而不是让团队胆战心惊，小心翼翼，这是创新的大敌，所谓创新有时候就是一种小范围的试错，合规的前提下鼓励试错）；其次是blameless是如果有问题那就让问题尽早出现的devops另一原则，fail fast；再者，blameless让问题及时反馈，符合向上游靠拢的原则。
+
+没有blame，不骂人，领导总是担心没有震慑力，底下人不能好好干活，典型专制政府型思维，官僚文化
+
+那么，问题是，据我所知，blame是很多组织领导驱动执行力的手段，blameless不是自废武功？
+为什么政府强调问责，中国政府问责制是很厉害的，甚至是终生问责，秋后算账都不鲜见，最近新冠疫情，光武汉就已经[问责处理654人，涉局级干部10人](https://www.jiemian.com/article/4051360_foxit.html)，这个除了中国历史历来的运动式治理的需要，另一个重要原因就是保持中央权威和执行力的需要，确保中央绝对能够指挥地方。这就跟一个组织的目标有关系，政府的目标宏观上一定是统一压倒一切，稳定压倒一切，政府属性压倒一切，而这一切的基础就绝对权威，在这个目标下，必须问责，没有机会问责，甚至可以创造机会问责，比如刘邦胡兰案，乾隆叫魂案，文革。经济和科技领域当然不是稳定压倒一切了，稳定过度就是压制创新，打压进步和压制发展，这就是为什么政府部门“一管就死”的原因吧。
+那么企业呢？
+
+
+---
+if you can not measure it , you can not manage it
+- 管理大师 彼得德鲁克
+---

devopscertificate.md

@@ -0,0 +1,179 @@
+# devops master certificate
+
+1. 验收测试的最佳选择? Happy Path
+2. 创建可执行文件的工具是一种什么样的构建工具? Make, 面向产品
+3. 一出问题就骂外包: 加强协作, 不指责.
+4. 告诉老板Devops能带来哪些效果: 快速发布, 降低成本, 直接支持业务产出
+5. DevOps开始时要做什么? 愿景, 目标.
+6. Devops团队的成员? 6-8人, Cross function 跨职能
+7. 紧急变更打补丁? RFC 申请变更, 分析影响, 通知利益相关方
+8. 云计算的哪个特性能实现自动部署? 标准栈
+9. 云的哪个特性不让人放心想上云? 安全, 服务级别(SLA)
+10. 哪个不是实现良好配置管理的策略?不能把二进制放到配置管理中
+11. 什么是管理基础设施的原则? 原则是后面个自动化, 版本控制, 监控
+12. 什么是构建依赖, 什么是运行依赖? 编译是构建依赖
+13. 手动软件发布过程的优点? 加强协作, 加强Review
+14. 什么不是部署管道的一部分?
+15. 一个新版本每三个月发布一次是Devops实践? 迭代中要进行增量发布
+16. 为什么SLA对客户如此重要?  对客户有价值
+17. 发生故障是基础设施重建? 自动化提供自动化运维
+18. SOR? 协作型
+19. 向其他同事抱怨不直接发生冲突? 避免/回避
+20. DevOps Mindset?  非谴责, 高效, 亲和
+21. 什么是协作? 多人根据输入达成共同的输出
+22. 什么是亲和? 不同群体
+23. 如何使Devops更加成熟? 戴明环, KAIZEN, 可视化控制和可视化管理.
+24. Devops文化转变包含什么? 新和, 协和, 高度信任, 同理心, 不谴责, 单件流
+25. 项目在DevOps中取得成功必须改变什么? Mindset,  千万不要选工具
+26. 重复可靠是指什么过程? Release
+27. Devops反模式? 手工发布, 开发完后才部署
+28. 迭代时间和频次取决于什么? 业务需求
+29. 持续部署的优点? 性能和一致性不相冲突
+30. Obeya作战系统? 共享信息, 快速决策
+31. CI的好处? 更少的Bug, 更低的成本, 更快发现Bug
+32. 既能保证质量又能提高发布效率?单件流
+33. 构建失败时应该怎么解决? 谁提交失败谁负责修复o
+
+---
+DevOps白皮书
+第1部分:A journey to DevOps The DevOps framework should support business outcomes directly。 
+
+第2部分:What is DevOps for the enterprise system? DevOps can also enable maturity by using W.E. Deming’s Plan Do-Check-Act cycle.
+
+第4部分DevOps Body of Knowledge:第四节TPS (Lean) concept as foundation :Building a stream-lined supply chain of IT services is difficult because there are many  items and it is necessary to change your mindset from the familiar existing development cycle and its methodologies.(JIT means building up a stream-lined supply chain with one-piece 
+flow.) 
+
+第4部分 DevOps Body of Knowledge:IT service management Service on just providing quick and frequent IT services and reliable operation and is led by the service  master. It is most suited for SoE and SoR continuity is an essential part of the warranty (fitness for purpose) of a service. If service  continuity cannot be maintained and/or restored in accordance with the requirements of the business, then the business will not experience the value that has been promised. Without continuity, the utility (fitness for use) of the service cannot be accessed.
+
+第 5 章角色职责: Leads the team and facilitates, this role is the same as “Scrum Master” in Scrum.Implements visual control across the entire process and has a strong focus on establishing a stream-lined process with one-piece flow.
+
+第5部分:DevOps Team Roles (Leads the team and facilitates, this role is the same as “Scrum Master” in Scrum. Implements visual control across the entire process and has a strong focus on establishing a stream-lined process with one-piece flow.) 
+
+第5部分:Gatekeeper / Release coordinator: Responsible for  monitoring the operational status and progress of the next release of the IT service. Make go/no go decisions about deployment according to criteria including security, compliance, regulatory requirements, maturity of operation team and their process views.
+
+第7部分:DevOps Process Project Planning The service master creates the vision, goal, and value of the project, and then puts together the DevOps team members. 
+
+第 7 章 JKK 解释：它基于 100％完成高质量项目创建完成定义
+
+第7部分:DevOps Process Obeya is a war room which serves two purposes - information management and on-the-spot decision making.
+
+第8部分 DevOps implementation Collaboration: (Standard): This focuses on just providing quick and frequent IT services and reliable operation and is led by the service  master. It is most suited for SoE and SoR 
+
+DEVOPS团队由 6-8 名成员组成的跨职能团队。
+
+The Service Master EOL
+
+精益管理中的八大浪费类型
+
+持续交付第11章基础设施和环境管理 225页：自动化的准备工作与自动化维护相结合，可保证出现问题就能在可预见的时间内重建基础设施。
+
+持续交付第11章 11.7.2章节 虚拟环境和部署流水线。250页 构建和发布管理系统应该能记住用来运行部署流水线的虚拟机模板，当部署到生产环境时，也应该能够启动同一套虚拟机模板。
+
+持续交付第四章 测试策略的实现 71页当你有时间写更多的自动化测试时，很难在Happy Path和Sad Path之间进行选择。 如果你的应用程序比较稳定，那么Happy Path应该是你的首选，因为它们是用户所定义的场景。
+
+持续交付第4.3章节 75页制定遵守INVEST原则[即独立的（Independent）、可协商的（Negotiable）、有价 值的（Valuable）、可估计的（Estimable）、小的（Small）且可测试的（Testable）] 的用户故事[ddVMFH]及考虑其验收条件。
+
+持续交付第15章 持续交付管理：340页企业治理更关注于符合度 （conformance），即遵从性、保障、监管、责任和透明管理， 而业务治理（business governance）更关注业务和价值创造的执行度（performance）。其实，执行度和符 合度都可以满足。这一道理在持续交付中也是正确的。通过确保交付团队能得到应用 程序在类生产环境上的不断反馈， 是部署流水线达成“执行度”这个目标的方法和手段。部署流水线使交付流程更加透明，来帮助团队达成符合度
+
+持续交付 5.4 提交阶段 97页
+
+15.3章节 344页：我们的关注点在于迭代和增量交付，以及跨功能职责角色之间的协 作。345页：Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。包括一系列 实践和预定义角色的过程框架。347页 开发与发布：我们推荐以迭代增量式过程进行软件 的开发与发布。
+
+第3章 持续集成 44页 高效使用持续集成 的那些团队能够比那些没有使用它的团队更 快地交付软件，且缺陷更少。在交付过程 中，缺陷被发现得越早，修复它的成本就越低， 因此也就大大节省了成本和时间。因 此我们认为，对于专业的软件交付团队来说，持续集成与版本控制同等重要。
+
+持续交付 3.7 章节 60 页从技术角度上看，最为简单的方法（也是从流程角度上讲最有效的方法）就是使 用共享的版本控制系统和持续集成系统。 63 页 3.8 章节：，DVCS 引入了一个中间层：在本地工作区的修改必须先提交到本地库，然后才能 推送到其他仓库，而更新本地工作区时，必须先从其他仓库中将代码更新到本地库。以及 14.4 章节
+
+持续交付第五章。什么不是部署管道的一部分？88页
+
+6.2 章节 构建工具：117 页 各构建工具的不同点在于它是任务导向的，还是产品导向的。任务导向的 构建工具（比如 Ant、NAnt 和 MSBuild）会依据一系列的任务描述依赖网络， 而产品导 向的工具，比如 Make（创建可执行文件），是根据它们生成的产物（比如一个可执行文件）来描述。
+
+项目失败：转向持续部署模式的最佳第一步是什么？开发应非正式地涉及整个项目的运维，并合作共同创建部署脚本。
+
+哪种做法有助于在不影响质量的情况下提高速度？One-piece-flow
+
+手动软件发布过程的优点是什么？鼓励协作，团队成员则审查彼此的工作。
+
+第八章：自动化验收测试 154 页：首先，由于反馈环将 大大缩短，缺陷被发现得更快，也就更容易修复。其次，由于测试人员、开发人员和 客户需要紧密合作才能创建一个良好的自动化测试套件，这会促进他们之间的良好合 作，而且每个人都将关注软件应该交付的业务价值。
+
+第 3 章，3.5.1 52 页、53 页  您的同事说：“即使构建中断，您也应该Check In。
+
+老板问实施DevOps，What would not be a good reason? 团队解释了新实践在另一家公司中的运作方式。
+
+8.5.1 验收测试中的状态 p167首先，要抵制使用生产数据的备份作为验收测试的测试数据库的诱惑（尽管有时 它对吞吐量测试是有用的）。相反，我们要维护一个受控的数据最小集。测试的一个关 键方面是建立一个确知的起始点。通过生产数据的副本以进行测试。
+
+12.4 章节 数据库回滚和无停机发布 P268
+
+11.9 基础设施和应用程序的监控 p257 收集数据、记录日志、建立信息展示板、行为驱动监控。提出了四种可能的操作来排除应用程序故障 1,2&4
+
+13.5.5 循环依赖。 P302 循环依赖构建阶梯
+
+13.3 依赖 P286 构建时依赖与运行时依赖之间的区别如下：构建时依赖会出现在应用程序编译和链接时（如果需要编译和链接的话）；而运行时依赖会出现在应用程序运行并完成它的某些操作时。
+
+第 2 章 配置管理 P24 进行增量更改，满足我所在组织的所有合规性规定
+
+第 11 章 基础设施管理 P224  第 11 章 基础设施管理 P224
+准备部署环境的过程以及部署之后对环境的管理是本章的主要内容。然而为了能 够做到这一点，就要基于下面这些原则，用一个整体方法来管理所有基础设施。 ①   使用保存于版本控制库中的配置信息来指定基础设施所处的状态。  基础设施应该具有自治特性，即它应该自动地将自己设定为所需状态。  通过测试设备和监控手段，应该每时每刻都能掌握基础设施的实时状况。 什么不是管理基础设施的原则？编写新的通用基础管理脚本。
+
+2.2 章版本控制 P27  什么不被认为是实现配置管理这一目标的有效策略？始终将二进制文件和配置信息保存在一起。
+
+11.8.1 P254  Cloud 安全和服务水平
+
+11.8.2 云中平台 P255 将应用部署到完全标准化的应用栈上，就意味着不需要担心测试环境、试运行 环境和生产环境的配置和维护，也不需要担心虚拟机映像的管理。最后一点尤其是革命性的。在本书中，用了大量的篇幅来讨论如何自动化你的部 署、测试和发布流程，以及如何搭建和管理测试和部署环境。云中的哪个平台特性最能实现自动部署？ Standardized stack
+
+10.5 紧急修复 P216  任何情况下，都不能破坏流程。紧急修复版本 也要走同样的构建、部署、测试和发布流程，与其他代码变更没什么区别。发布 RFC 作为紧急补丁并通知所有利益相关者。 然后根据 SLA 应用紧急补丁。P216
+
+---
+高效的 DevOps 文化需要具备：高效沟通，共识与信任，人性化的员工配置和资源
+写一份项目章程很重要，一起写项目范围最好的理由是什么：确保所有团队对成功有着相同的定义
+衡量已找到程序错误的总数是跟踪项目质量最好的方法吗：全局范围内而非局部进行优化
+服务级别协议对专注于増加商业价值有所帮助
+
+---
+1. 场景：5 个月 h 后……，开发完成后才向类生产环境部署（考点，反模式）
+2. 在发布流程为软件发布创建一个可重复且可靠的过程。（考点，软件交付原则）
+3. DEVOPS 应该建立一个 Pull System、One Piece Flow 的 IT Super Chain
+4. 建立 DEVOPS New Mind of All People，流程 One Piece Flow
+5. 场景：一家公司由于供应商的要求，只剩下 5 个月的时间建立 DEVOPS 的团队，他 们如何决定他们的迭代时间和频次？ 根据符合业务要求来确定
+6. DEVOPS 四个支柱 Collaboration，Multiple People
+7. 要进行 DEVOPS 转型，Coach Team 中的每一个人，建立 Blameless 的文化 
+8. DevOps 转型：沟通、同理心、人员和资源
+9. 场景：CEO 以前总是骂下面的人，现在采用了 DEVOPS 方式，情况有所好转，但是 没有达到理想效果，应该：Trust each Other，建立 Blameless 文化
+10. 一个人抱怨另一个人，通过邮件到处宣扬对另一个人的不满，Avoidance
+11. Gatekeeper 的职责：Security、Compliance、Regulatory Requirements
+12. 浪费的类型：Extra Feature
+13. 在 DEVOPS 项目计划时，SLR 包含那些内容、安全、连续性等内容
+14. DEVOPS 项目开始时要做那些工作？Vision、Goal 等
+15. SOR 适用月那种 DEVOPS 方式，Collaboration
+16. Obeya，信息共享，做决定
+17. Auto Provisioning  Auto maintenance
+18. VM 模板
+19. SLA 的重要性，业务连续性
+20. 在稳定没有时间的情况下进行：Happy Path 测试
+21. 场景：销售人员提出了一些列销售问题，这个用户故事符合 INVEST 原则？问选哪 一个：可测试性
+22. Development Pipeline 对治理的作用
+23. 提交阶段需要做什么工作？
+24. 一个团队三个月进行一次新版本的部署，而且是按照模块开发和部署，因此他们认 为他们的采用的是 DEVOPS 的方法，选项问适和否
+25. 持续集成的优势 fewer bug、cheaper
+26. Check In polices
+27. Run time Build time
+28. 安全问题出现后，如何进行紧急变更
+29. 谁可以决定服务终止
+30. 数据库管理，此题是技术题，大概内容是要做一个回退脚本，且要保证原有数据不 能删除，但可能重构表内容。
+31. 不上云的理由，安全，SLA
+32. Standardized stack
+33. 手工发布软件的优势
+34. 手工测试的类型
+35. 场景：某人要提交有问题的代码，且振振有词讲到提交后可能通过变更进行更正。 
+36. 循环依赖
+37. Ensures performance (fast delivery) and conformance (to requirements
+38. 不要将生产数据库拿到测试环境
+39. JKK 100%质量覆盖
+40. 版本控制，巴黎，伦敦，悉尼，还有其他地方存在时差，如何进行版本控制
+41. 基础架构环境准备
+42. Cross Function 的 6-8 人
+43. 不要把二进制文件放进构件库中
+44. Make such as an Executable
+45. Product Oriented
+46. Process Master 的职责，建立可视化看板，单件流等 
+47. 配置管理策略，增量，合规
+48. Increase speed without compromising quality

devopsmaster证书.md

@@ -0,0 +1,7 @@
+
+# devops master certificate
+
+## 我的devops master证书
+![devops成绩.png](https://i.loli.net/2020/09/06/fIbFGrNPsow9YUJ.png)
+![devops成绩分析.png](https://i.loli.net/2020/09/06/6BFKTwjcumv8gDS.png)
+

devopssummary.md

@@ -0,0 +1,116 @@
+
+# devops master summary
+
+- 是什么？文化？
+- devops实践？
+- devops工具？
+- 价值流具体化、可视化？
+- 需求拆分技术？
+- BA QA/Tester Dev - BDD技术？
+- 谁决定能不能上线？
+
+
+# 要点
+1. DevOps Mindset? **非谴责**, 高效, 亲和
+1. Devops文化转变包含? 亲和, 协作, 信任, 同理心, 不谴责, **单件流**  **Trust each Other，Blameless**
+1. DevOps方法论: PDCA，KAIZEN，可视化控制&管理（obeya作战室：共享信息, 快速决策）
+1. 聚焦软件交付的业务价值（持续、顺畅、高质量交付有效价值）
+1. 创建一个**拉式部署流水线**
+1. 质量内建 + 面向上游（从Ops到Dev） + **人人对质量负责**
+1. 部署脚本：使用同样的部署脚本在不同环境中部署，确保部署流程幂等性
+1. 尽早发现问题(编译错误，测试失败，环境问题让提交失败) **fail fast fail cheap**
+1. 任何情况下，都不能破坏流程。紧急修复版本也要走 构建/部署/测试/发布的流程，与变更没区别
+1. 发布：蓝绿发布，金丝雀发布, AB测试
+1. 紧急修复 or 回滚
+1. 基础设施重建：Auto provisioning - auto maintainance
+1. 创建**类生产环境**，环境配置变更应能够触发流水线
+   确保交付团队能得到应用程序在类生产环境上的不断反馈
+1. 创建监控策略：collect, store, dashboard, log, monitor
+1. 企业治理：
+    - 符合度(conformance)，合规性，关注遵从性，保障，监管，责任，透明管理
+    - 执行度(performance)，绩效，关注业务和价值
+1. 验收测试的最佳路径**happy path**
+1. 交付过程中，缺陷被发现得越早，修复它的成本就越低 fail fast
+1. **拉灯**
+
+紧急变更不应该成为不走变更流程的理由
+
+#### 精益8大浪费 DOWNTIME
+
+| type | description | 解决 |
+| ---- | ---- | ---- |
+| defect | 缺陷 | poka-yake(防错设计) |
+| overproduction | 过度生产 | 可视化，拉动生产 |
+| waiting | 等待 | 识别约束，减少等待 |
+| non-utilized people | 未充分利用人员 | kaizen，学习型组织 |
+| transportation | 搬运 | 单件流 |
+| inventory | 库存 | 可视化，拉动生产 |
+| motion | 动作 |  |
+| extra processing/feature | 镀金 | 5why |
+
+#### 需求/用户故事原则 INVEST
+
+type | x
+-- | --
+独立的（Independent） | 解耦
+便于沟通（Negotiable） | 减少与客户等相关方的沟通成本
+有价值的（Valuable） | 对客户有价值
+可估计的（Estimable） | 开发者便于估计工作量
+小的（Small） | 短小有代表性，敏捷迭代
+可测试的（Testable） | 用户故事已完成的标准，或者说能够确认已完成
+
+
+#### 个人实践
+
+关于测试
+1. 类生产环境作为beta测试环境，可以是本地资源
+2. 生产中把部署和发布解耦，发布采用金丝雀或蓝绿，蓝绿对资源要求太高，采用金丝雀发布，测试/支撑/业务人员对金丝雀做小批量验证，只验证主流程，做冒烟。用Prometheus做pod监控。
+3. 验证有问题，删除新版本Pod；验证通过，新版本Pod扩展到老版本资源。
+
+
+```
+约束点在哪里？ --> 如何改善约束点？ --> 突破约束点 -->
+  ^                                                  |
+  |__________________________________________________|
+
+可能约束点
+1. 环境搭建
+2. 代码部署
+3. 测试的准备和执行
+
+监视缺陷和镀金
+
+```
+
+
+开发运维“三步工作法”，它旨在阐明指导开发运维的流程与实践的价值观与理念。
+
+### 第一工作法
+是关于从开发到IT运维再到客户的整个自左向右的工作流。**为了使流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心**，并且不断为了整体目标（相对于开发功能完成率、测试发现/修复比率或运维有效性指标等局部目标）进行优化。必要的做法包括持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。
+
+### 第二工作法
+是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。这样，我们就能在所需之处获取或嵌入知识，从源头上保证质量。
+
+“必要的做法包括：在部署管道中的构建和测试失败时“停止生产线”；
+日复一日地持续改进日常工作；创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态；
+在开发和IT运维之间建立共同的目标和共同解决问题的机制；
+建立普遍的产品遥测技术，让每个人都能知道，代码和环境是否在按照设定的运行，以及是否达到了客户的目标。
+
+### 第三工作法
+是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。”
+
+“尝试和承担风险让我们能够不懈地改进工作系统，这经常要求我们去做一些与几十年来的做法大不相同的事。一旦出了问题，不断重复的日常操练赋予我们的技能和经验，令我们可以撤回至安全区域并恢复正常运作。
+
+必要的做法包括营造一种勇于创新、敢于冒险（相对于畏惧或盲目服从命令）以及高信任度（相对于低信任度和命令控制）的文化，把至少20%的开发和IT运维周期划拨给非功能性需求，并且不断鼓励进行改进。
+
+
+
+### references
+- [使用Kubernetes演示金丝雀发布](https://www.cnblogs.com/rexcheny/p/10740536.html)
+- [istio完成金丝雀、灰度发布](https://blog.csdn.net/qq_42150559/article/details/96136245)
+- [使用原生k8s及helm完成灰度(金丝雀)发布](https://blog.csdn.net/qq_42150559/article/details/97143825)
+- [Kubernetes的部署策略，你常用哪种？](https://www.sohu.com/a/318731931_100159565)
+
+
+- [写给新人的BA工作说明书](https://www.jianshu.com/p/9efbf1233a7e)
+- [DevOps实施：从敏捷文化与配置文件的困惑说起](http://www.suphp.cn/yunweipai/35/23835.html)

devopstest.md

@@ -0,0 +1,483 @@
+# devops测试
+
+## 一、选择题（20）
+
+1. 验收测试的最佳选择?
+a. Happy Path
+b. 回归测试
+c. alternate Path
+d. Sad Path
+
+a. happy path 相当于做主流程
+
+2. 云计算的哪个特性能实现自动部署? 
+a.  标准栈
+b.  规模化
+c.  虚拟化
+d.  通用性
+
+a. 标准栈使得自动部署成为可能
+
+3. 软件交付过程中，让整个过程自动化，并能够及时发现问题和修复问题，在此过程中,以下实践不是反模式选项是：
+a，要求一份详尽文档，该文档描述了每个步骤中容易出错的地方
+b，开发完成后才向类生产环境部署
+c，提前频繁的做让你感到痛苦的事
+d，手工进行生产环境的配置
+
+c. 痛苦的事情频繁做
+
+4. 良好的配置管理过程，是实现开发和部署过程可控和可重复的基础，以下哪个内容不是良好配置管理策略：
+a. 能够再现所需的任何环境。
+b. 为了达到系统运行稳定的目标，固化配置，任何修改都做登记。
+c. 能够追踪某个具体环境的某次修改，并能够追溯修改源，以及什么时间谁做了修改。
+d. 增量式修改，并可将修改部署到任意一种环境中。
+
+b. 不是敏捷策略。影响迭代。
+
+5. 每个应用程序都依赖于软件、硬件、基础设施等才可以正常工作，这些内容称作应用程序的环境，环境管理与配置管理同样重要。以下哪种不是良好的环境管理实践：
+a. 环境管理的关键是通过一个自动化过程来创建环境。
+b. 因为环境管理的重要性，一旦系统出问题，派遣资深专家花费不确定的时间来找到问题，并修复它。
+c. 修复某个环境可能需要大量时间，因此，最好在可预见的时间里重建环境，并将其恢复到某个已知的正常状态。
+d. 创建一个类生产环境，配置问题可在早期测试中发现。
+
+b. 1. 自动化、简单化、可量产、可重现，不是依赖资深专家
+
+6.  公司打算构建一条部署流水线，公司领导希望实现频繁发布。
+有团队成员认为：这条部署流水线最重要的是自动化。团队首先要让它自动化起来。
+这种说法对吗？
+a.  是的，这是正确的。部署流水线自动化是提升效率的最重要因素。
+b.  是的，这是正确的。关注自动化部署流水线的创建，克服之后可能遇到的潜在问题。
+c.  不，这是错误的。完成单件流及一个可靠的部署流程是优先级最高的任务。该流程的自动化可以暂缓实施。
+d.  不，这是错误的。首先应当自动化的是测试流程而非部署流水线。
+
+c, 无论何时，所有部署流水线首先应当是单件流程的部署流水线，无需自动化就可高效运行。一旦该流水线稳定确立，就有机会选择可行的流程实施自动化。但是，构建稳定的部署流水线永远比自动化更重要。
+
+7. 有很多方法可以使组织趋向成熟，下列哪种方法不会使你的devOps组织更趋成熟？
+a. 明确定义目标定和里程碑，帮助团队成员判断其日常活动是否有价值。
+b. 明确定义流程，支持并促使团队成员逐日改进流程。
+c. 对会议的所有内容进行记录，使你的团队成员可以很方便的了解到每次沟通的内容信息。
+d. 监控并记录每天的活动，以找出小范围内每天取得的进步并予以赞扬。
+
+c, 这无助于devOps组织的成熟。是否要对会议进行全程记录并再次审查，并没有严格的要求。有必要记录达成共识的内容，而不是记录整 场会议。（文献：持续交付，第十五章）
+
+8.  你认为自己的开发团队是一支真正的团队。
+你觉得有什么确切的特征表明这是一支团队而不只是一个小组呢？
+a.	该团队遵守在团队会议中共同制定的规则。
+b.	团队召开自己主持的高效会议。
+c.	团队以稳定的工作节奏，朝着共同的目标推进。
+d.	该团队通过质询负责某项工作的团队成员的方式来解决问题。	
+
+d 一支真正的团队能够维持稳定的工作节奏，并能够始终向着共同的目标努力。（文献：Effective devOps，第九章）
+
+9.
+为采用整体方法处理所有基础设施，应当遵循哪两条原则?
+a.
+1.	你的基础设施应具备的状态需要通过变更控制配置来确定。
+2.	你应当通过监控与事件管理，及时了解基础设施的准确状态。
+b.
+1.	需要通过变更控制配置来确定你的基础设施应具备的状态。
+2.	你应当通过仪器仪表及事件管理，始终了解基础设施的确切状态。
+c.
+1.	你的基础设施应具备的状态需要通过版本控制配置来确定。
+2.	你应当通过当前事件与事件管理，始终了解基础设施的确切状态。
+d.
+1.	你的基础设施应具备的状态需要通过版本控制配置来确定。
+2.	你应当通过仪表盘与监控始终了解基础设施的确切状态。
+
+d, 为采用整体方法处理所有基础设施，应当遵循这两条核心原则。（文献：持续交付， 第十一章）
+
+10.
+在敏捷和devops中吸收了很多精益核心概念。实施devOps时，将精益的相关概念应用在devOps过程中，有助于成功实施devops。
+在此过程中，精益管理的哪些原则或实践方法最有效?
+
+a) Kaizen(专有词，意为小的、不花钱的持续改善)
+b) 5S - 整理（SHIRI）、整顿（SEITON）、清扫（SEISO）、清洁（SEIKETSU）、素养（SHITSUKE）
+c) Obeya系统(可视化管理)
+d) 单件流与质量检查
+
+d,
+创建一个可行的、单件部署流水线将有 助于成功实施devOps。devOps中最重要的工作在于构建从开发部门到运维部门的上游流程，尤其是针对单一部署流水线。质量检查（JKK）是能够达成这一目标的最有效的工作行为。（文献：《企业devOps的成功之路》）
+
+
+11.  持续集成不会单独的帮你修复构建过程，在中后期开展持续集成，意味着在构建过程需要耗费大量工作。
+为了使持续集成更高效，早期阶段，一般不会涉及的工作是？
+a. 频繁提交代码到版本控制库
+b. 创建分支，并尽早提交代码到分支
+c. 创建自动化测试套件
+d. 保持较短的构建和测试过程
+
+b. 应提交到主干，分支容易破坏即时集成
+持续交付 P46
+
+12.  关于版本控制，以下说法不正确的是？
+a. 源代码必须纳入版本控制。
+b. 配置信息必须纳入版本控制。
+c. 为了加快发布周期和提高软件质量，将编译器或其他相关工具的二进制镜像纳入版本控制。
+d. 为了加速打包，将源代码编译后的二进制文件纳入版本控制。
+
+d. 不推荐，1. 比较大，2. 每次重新构建都会重新生成二进制文件，无必要
+
+
+13. 一个开发团队对devOps感兴趣。他们主要感兴趣的对象是持续集成（cI）。他们目前开发并维护着三种主要解决方案及四种次要解决方案。他们采用Scrum实践方法。每次冲刺都需要四周时间，平均每十天到十五天对测试环境都有一次提交发布，平均每个月对生产环境有一次发布。他们想为管理层制定一个定性的商业论证，来支持他们为创建持续集成实践模式而付出的投资与努力。
+持续集成有哪些显性收益对该商业论证最为有利？
+a. 每天对测试环境进行一次部署能极大的提高商业效益并且大大缩减开发成本。
+b. 这有助于提升团队精神。由于公司已经在使用Scrum，持续集成将为公司业务带来显著的益处。
+c. 它通过更好的集成测试提高了业务稳定性，同时维持发布速度以防止产生额外成本。
+d. 在生产环境中，每天进行一次信息发布能够提升业务收益，并大大减少开发成本。
+
+d, 更快速的向生产环境发布是持续集成的一大主要益处，此外还包括更快速地发现故障以减少开发成本和故障修复成本。（文献：《持续交付》， 第三章——持续集成）
+
+14.  关于使用脚本去构建和部署流程自动化，以下说法正确的是？
+a. 每种环境采用一个脚本，并将其作为版本控制系统的一部分加以维护。
+b. 不同环境使用不同的特定脚本，以解决环境之间的差异问题。
+c. 不同环境采用同样的脚本，对特定的配置采用手动参数。
+d. 采用同一脚本在不同环境中进行部署，并单独管理配置信息。
+
+d,
+脚本应当保持一致，才能保证构建和交付流程得到有效测试。环境之间（如URI和IP等）的差异应当作为配置管理流程的一部分予以处理。（文献：《持续交付》，第六章——构建 与部署脚本处理的原则与方法）
+
+
+15. 当有运维侧变更时，运维部门告知开发部门的最佳时间是何时？
+a. 无需告知开发团队。运维侧的变更仅运维团队知晓即可。
+b. 立刻执行。应当尽快通知开发部门。
+c. 次日早晨的Scrum会议中。
+d. 当运维团队已经完成验收测试时。
+
+b, 应当立即告知开发部门，让他们能够预见潜在的风险和问题。（文献：企业级devOps的成功之路）
+
+16. 考虑对基本部署流水线进行具体解析。
+哪个阶段表明该系统在功能性与非功能性层面均发挥作用？
+a. 自动化验收测试
+b. 构建与单元测试
+c. 手动验收测试
+d. 版本控制
+
+a. 自动化验收测试阶段表明，系统在功能性与非功能性层面上工作正常，在行为上它能满足用户的需求和客户的规格要求。（文献： 《持续交付》，第八章）
+
+
+17. 开发团队当前在测试中遇到诸多挑战。目前他们使用人工验收测试流程。
+开发者认为他们所创建的单元测试是十分周密的，可以避免回退。
+在每次发布时，开发团队都需要花费100万在人工验收测试环节。
+领导层要求开发团队实施自动化验收测试，以降低测试的总成本并尽可能减少引入生产环境中的代码缺陷数量和回退次数。
+在依照自动化需求确定应用程序的验收标准时，应当遵循什么原则？
+a. agile（敏捷）原则
+b. aTaM（架构权衡分析法）原则
+c. dIVEST原则
+d. INVEST原则
+
+d, 验收测试源自验收标准，因此你的应用程 序的验收标准的制定应当考虑自动化因素，遵循INVEST原则；
+Independent (独立性)、Negotiable (可协商)、Valuable(有价值)、Estimatable(可估计)、Small(小而少)、Testable(可测试)（文献：持续交付，第八章——如何创建可维持的验收测试套件）
+
+
+18. 自动化测试是高效软件发布和实现持续交付的基础，以下那一类测试不宜全面自动化。
+a. 容量测试
+b. GUI测试
+c. 单元测试
+d. 探索性测试
+
+d. 探索性测试一般需结合人工测试
+
+19.
+公司正在使用devOps。该公司实施了持续部署，并具备高度自动化验收测试和每日向生产部交付新软件的稳定部署流水线。公司有一个巨大的数据库及众多用户。该公司具备全面可靠的容量测试策略。由于该公司环境广大而复杂，随着每个新版本的发布，生产部就会出现一些小故障。
+什么策略能够最有效地帮助该公司预防这些故障？
+a) 采用金丝雀发布
+b) 自动化容量测试
+c) 降低交付率
+d) 采用蓝绿部署
+
+a. 金丝雀发布包括向生产服务商中的一小部分推出新版本的应用程序，以快速收集反馈。这能够快速发现新版本中出现的所有问题，而不会对大多数用户产生影响，因为工作量是逐渐增长的；同时这一做法还能确定响应时间及其他工作表现衡量标准，减少新版本发布的风险，并帮助尽快发现与修复漏洞。（文 献：持续交付，第十章-金丝雀发布）
+
+蓝绿部署需要大量资源，因而在该情境 中代价高昂。此外，若需要回退，在大型数据 库中采用这一策略可能导致故障或只读情况发 生。另外，这也无助于容量测试效率的提高。
+
+20.  公司正在尝试转变，并开始使用devOps的方式开展工作。你的团队也在经历这一转变。
+你正在参与讨论代码提交阶段的最佳实践。
+某同事说：“当某一构建遭到破坏且无人担责时，我们应当找出造成破坏的人并要求他们展开工作，以保证他们能修复这一构建。”
+这样做合适吗？
+a. 是的。只有破坏构建的人才能够修复它，因此你应当找到负责人，即使这样可能会让人感觉不舒
+服。
+b. 是的。你应当始终为破坏构建负责。如果你不负责，你的同事将可能强制执行这项规定。
+c. 不，devOps环境中不存在追责。若同事不承担责任，不要强迫他们。
+d. 不，你应当首先修复构建。然后抽出时间，确定相关负责人并进行处罚。
+
+c, Devops文化不提倡强迫任何人做任何事。犯错是可以接受的。团队成员共同协作以克服各种错误或挑战。（文献：持续交付，第三章；高效的 devOps，第一部分）
+
+
+## 二、简答题（5）
+1. 简述devops能带来哪些效果？
+    快速发布
+    降低成本
+    持续反馈，提高软件质量
+    更关注业务产出，给客户带来价值
+
+2. 每个系统都会遇到这种情况：发现一个严重缺陷，必须尽快修复。简述紧急变更过程?
+    需牢记：任何情况下，都不能破坏流程，紧急修复版本同样走构建、部署、测试、发布流程，与其他代码变更没有区别。
+      申请变更(Request for change,RFc)
+      分析影响
+      通知利益相关方
+
+3. devops文化转变包含哪些?
+    高效
+    亲和
+    协作
+    高度信任
+    同理心
+    非谴责
+    单件流
+
+4. 持续集成不光是一些工具组合，更是一种实践，它的有效性也依赖于团队纪律。简述cI(持续集成)的好处，及为了实现持续集成目标，有哪些良好的实践?
+    好处：
+      软件在任何时候可工作
+      更少的bug
+      更低的成本
+      更快发现bug
+    良好实践或纪律：
+      构建失败后不要向版本库提交新代码, 确保软件一直可工作
+      本地构建并运行提交测试，测试通过才继续工作
+      不要将失败的构建注释掉
+      为自己导致的问题负责
+      所有人为质量负责
+      ...
+     
+ 5.  在自动化运维中，要实现基础设施和应用程序的监控策略，通常要考虑哪些方面内容或从哪些方面着手？
+      采集数据，软硬件运行情况，健康度，统计信息等, 通过SNMP/TR069等
+      记录日志，解析、分析、统计日志文件，并关注日志等级
+      建立信息展示板(dashborad),可视化
+      建立自动通知/告警机制
+
+## 三、论述题（2）
+1. 在软件发布过程共，我们常常看到测试、运维、开发团队协作不畅导致的流程受阻，部署流水线从端到端来贯穿流程，实现自动化构建、部署、测试和发布。公司推进敏捷/devops，请结合实践，论述如何构建一套部署流水线，以及这套部署流水线如何在实践中更好的实现持续交付。
+
+内容要点：
+结合实践来阐述
+     1. 部署流水线流程
+          提交,版本控制库
+          自动构建和单元测试（可能涉及自动配置管理）
+          部署二进制包
+          自动化验收测试(一般做冒烟测试，也可能包括自动化容量、安全等非功能性测试)
+
+          运维一键部署到生产环境（容器化,生产环境配置，部署二进制包）
+
+          流程的起点是开发人员向版本控制库提交代码，流水线对提交作出响应，触发流水线的一个实例，编译代码，运行单元测试，执行代码分析，创建软件的二进制包；如果所有单元测试通过，代码符合标准，完成软件打包；之后触发自动化验收。
+       2. 构建流水线过程
+          对价值流建模并创建简单的可工作框架（比如流行的jenkins）
+          将构建和部署流程自动化
+          将单元测试和代码分析自动化
+          将功能（验收）测试自动化
+          将发布自动化
+       3. 一些良好实践
+          部署流水线的成功的关键之一是各个环节能够尽快得到反馈
+          项目较大情况下，全量或回归测试可能耗费大量的时间，可能打断持续集成效率，在流水线中往往只做冒烟测试，通常要在一两个小时内完成该过程。
+          确保生产中部署的包与流水线生成的二进制包是同一个，或者对包做HaSH验证。重新创建二进制包将带来不一致风险。
+          如果某个环节失败，应停止整个流水线。整个团队对失败负责。
+          象其他交付的应用一样，对部署流水线进行增量式实现，不断改善和重构。
+          让每个环节可视化，让大家能够清晰的看到哪个环节有什么问题。
+          
+
+参考<持续交付>第五章相关内容
+
+2. 
+一个电信级应用部署在云上，随着业务不断演进，系统用户和数据量不断增加，云资源的稳定性和系统的复杂性带来的系统服务中断的风险越来越大，系统中断的影响也随之增加。请结合实践，论述从哪些方面来提升系统可用性或提升系统容灾能力。
+
+从以下要点结合实践展开论述：
+
+架构手段：从以下角度结合应用进行分析：
+        - 冷、热备份，心跳检测保活
+              如通过LVS、haproxy、keepalive等方式
+        - 集群 & 负载均衡 & 分布式
+              负载均衡架构是多个服务做一堆同类的事情，每件事情相互独立；
+              分布式的架构则是将一件复杂的事情分解出多个部份，由多个服务去做，再通过架构实现多个分解事情处理结果的合并。
+        - 多中心，异地异机房，涉及负载分担和数据同步等问题的考虑
+        - 纵向扩容，如加服务器资源，换性能更强的服务器提升服务能力
+        - 横向扩容，对业务、数据库、区域等进行划分
+        - 业务服务的拆分
+        - 数据库的读写分离
+        ...
+
+运维手段：
+        - 虚拟化、容器化
+        - 监控手段，发现机制和加速处理机制等
+        - 演练和一些馄饨学工具故障模拟
+        - 自动化运维，监控预警等手段
+        - 应急预案
+        ...
+
+
+
+2. 创建可执行文件的工具是一种什么样的构建工具? Make, 面向产品
+3. 一出问题就骂外包: 加强协作, 不指责.
+4. 告诉老板devops能带来哪些效果: 快速发布, 降低成本, 直接支持业务产出
+5. devOps开始时要做什么? 愿景, 目标.
+6. devops团队的成员? 6-8人, cross function 跨职能
+7. 紧急变更打补丁? RFc 申请变更, 分析影响, 通知利益相关方
+8. 云计算的哪个特性能实现自动部署? 标准栈
+9. 云的哪个特性不让人放心想上云? 安全, 服务级别(SLa)
+10. 哪个不是实现良好配置管理的策略?不能把二进制放到配置管理中
+11. 什么是管理基础设施的原则? 原则是后面个自动化, 版本控制, 监控
+12. 什么是构建依赖, 什么是运行依赖? 编译是构建依赖
+13. 手动软件发布过程的优点? 加强协作, 加强Review
+14. 什么不是部署管道的一部分?
+15. 一个新版本每三个月发布一次是devops实践? 迭代中要进行增量发布
+16. 为什么SLa对客户如此重要?  对客户有价值
+17. 发生故障是基础设施重建? 自动化提供自动化运维
+18. SOR? 协作型
+19. 向其他同事抱怨不直接发生冲突? 避免/回避
+20. devOps Mindset?  非谴责, 高效, 亲和
+21. 什么是协作? 多人根据输入达成共同的输出
+22. 什么是亲和? 不同群体
+23. 如何使devops更加成熟? 戴明环, KaIZEN, 可视化控制和可视化管理.
+24. devops文化转变包含什么? 新和, 协和, 高度信任, 同理心, 不谴责, 单件流
+25. 项目在devOps中取得成功必须改变什么? Mindset,  千万不要选工具
+26. 重复可靠是指什么过程? Release
+27. devops反模式? 手工发布, 开发完后才部署
+28. 迭代时间和频次取决于什么? 业务需求
+29. 持续部署的优点? 性能和一致性不相冲突
+30. Obeya作战系统? 共享信息, 快速决策
+31. cI的好处? 更少的bug, 更低的成本, 更快发现bug
+32. 既能保证质量又能提高发布效率?单件流
+33. 构建失败时应该怎么解决? 谁提交失败谁负责修复o
+
+---
+devOps白皮书
+第1部分:a journey to devOps The devOps framework should support business outcomes directly。 
+
+第2部分:What is devOps for the enterprise system? devOps can also enable maturity by using W.E. deming’s Plan do-check-act cycle.
+
+第4部分devOps body of Knowledge:第四节TPS (Lean) concept as foundation :building a stream-lined supply chain of IT services is difficult because there are many  items and it is necessary to change your mindset from the familiar existing development cycle and its methodologies.(JIT means building up a stream-lined supply chain with one-piece 
+flow.) 
+
+第4部分 devOps body of Knowledge:IT service management Service on just providing quick and frequent IT services and reliable operation and is led by the service  master. It is most suited for SoE and SoR continuity is an essential part of the warranty (fitness for purpose) of a service. If service  continuity cannot be maintained and/or restored in accordance with the requirements of the business, then the business will not experience the value that has been promised. Without continuity, the utility (fitness for use) of the service cannot be accessed.
+
+第 5 章角色职责: Leads the team and facilitates, this role is the same as “Scrum Master” in Scrum.Implements visual control across the entire process and has a strong focus on establishing a stream-lined process with one-piece flow.
+
+第5部分:devOps Team Roles (Leads the team and facilitates, this role is the same as “Scrum Master” in Scrum. Implements visual control across the entire process and has a strong focus on establishing a stream-lined process with one-piece flow.) 
+
+第5部分:Gatekeeper / Release coordinator: Responsible for  monitoring the operational status and progress of the next release of the IT service. Make go/no go decisions about deployment according to criteria including security, compliance, regulatory requirements, maturity of operation team and their process views.
+
+第7部分:devOps Process Project Planning The service master creates the vision, goal, and value of the project, and then puts together the devOps team members. 
+
+第 7 章 JKK 解释：它基于 100％完成高质量项目创建完成定义
+
+第7部分:devOps Process Obeya is a war room which serves two purposes - information management and on-the-spot decision making.
+
+第8部分 devOps implementation collaboration: (Standard): This focuses on just providing quick and frequent IT services and reliable operation and is led by the service  master. It is most suited for SoE and SoR 
+
+dEVOPS团队由 6-8 名成员组成的跨职能团队。
+
+The Service Master EOL
+
+精益管理中的八大浪费类型
+
+持续交付第11章基础设施和环境管理 225页：自动化的准备工作与自动化维护相结合，可保证出现问题就能在可预见的时间内重建基础设施。
+
+持续交付第11章 11.7.2章节 虚拟环境和部署流水线。250页 构建和发布管理系统应该能记住用来运行部署流水线的虚拟机模板，当部署到生产环境时，也应该能够启动同一套虚拟机模板。
+
+持续交付第四章 测试策略的实现 71页当你有时间写更多的自动化测试时，很难在Happy Path和Sad Path之间进行选择。 如果你的应用程序比较稳定，那么Happy Path应该是你的首选，因为它们是用户所定义的场景。
+
+持续交付第4.3章节 75页制定遵守INVEST原则[即独立的（Independent）、可协商的（Negotiable）、有价 值的（Valuable）、可估计的（Estimable）、小的（Small）且可测试的（Testable）] 的用户故事[ddVMFH]及考虑其验收条件。
+
+持续交付第15章 持续交付管理：340页企业治理更关注于符合度 （conformance），即遵从性、保障、监管、责任和透明管理， 而业务治理（business governance）更关注业务和价值创造的执行度（performance）。其实，执行度和符 合度都可以满足。这一道理在持续交付中也是正确的。通过确保交付团队能得到应用 程序在类生产环境上的不断反馈， 是部署流水线达成“执行度”这个目标的方法和手段。部署流水线使交付流程更加透明，来帮助团队达成符合度
+
+持续交付 5.4 提交阶段 97页
+
+15.3章节 344页：我们的关注点在于迭代和增量交付，以及跨功能职责角色之间的协 作。345页：Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。包括一系列 实践和预定义角色的过程框架。347页 开发与发布：我们推荐以迭代增量式过程进行软件 的开发与发布。
+
+第3章 持续集成 44页 高效使用持续集成 的那些团队能够比那些没有使用它的团队更 快地交付软件，且缺陷更少。在交付过程 中，缺陷被发现得越早，修复它的成本就越低， 因此也就大大节省了成本和时间。因 此我们认为，对于专业的软件交付团队来说，持续集成与版本控制同等重要。
+
+持续交付 3.7 章节 60 页从技术角度上看，最为简单的方法（也是从流程角度上讲最有效的方法）就是使 用共享的版本控制系统和持续集成系统。 63 页 3.8 章节：，dVcS 引入了一个中间层：在本地工作区的修改必须先提交到本地库，然后才能 推送到其他仓库，而更新本地工作区时，必须先从其他仓库中将代码更新到本地库。以及 14.4 章节
+
+持续交付第五章。什么不是部署管道的一部分？88页
+
+6.2 章节 构建工具：117 页 各构建工具的不同点在于它是任务导向的，还是产品导向的。任务导向的 构建工具（比如 ant、Nant 和 MSbuild）会依据一系列的任务描述依赖网络， 而产品导 向的工具，比如 Make（创建可执行文件），是根据它们生成的产物（比如一个可执行文件）来描述。
+
+项目失败：转向持续部署模式的最佳第一步是什么？开发应非正式地涉及整个项目的运维，并合作共同创建部署脚本。
+
+哪种做法有助于在不影响质量的情况下提高速度？One-piece-flow
+
+手动软件发布过程的优点是什么？鼓励协作，团队成员则审查彼此的工作。
+
+第八章：自动化验收测试 154 页：首先，由于反馈环将 大大缩短，缺陷被发现得更快，也就更容易修复。其次，由于测试人员、开发人员和 客户需要紧密合作才能创建一个良好的自动化测试套件，这会促进他们之间的良好合 作，而且每个人都将关注软件应该交付的业务价值。
+
+第 3 章，3.5.1 52 页、53 页  你的同事说：“即使构建中断，你也应该check In。
+
+老板问实施devOps，What would not be a good reason? 团队解释了新实践在另一家公司中的运作方式。
+
+8.5.1 验收测试中的状态 p167首先，要抵制使用生产数据的备份作为验收测试的测试数据库的诱惑（尽管有时 它对吞吐量测试是有用的）。相反，我们要维护一个受控的数据最小集。测试的一个关 键方面是建立一个确知的起始点。通过生产数据的副本以进行测试。
+
+12.4 章节 数据库回滚和无停机发布 P268
+
+11.9 基础设施和应用程序的监控 p257 收集数据、记录日志、建立信息展示板、行为驱动监控。提出了四种可能的操作来排除应用程序故障 1,2&4
+
+13.5.5 循环依赖。 P302 循环依赖构建阶梯
+
+13.3 依赖 P286 构建时依赖与运行时依赖之间的区别如下：构建时依赖会出现在应用程序编译和链接时（如果需要编译和链接的话）；而运行时依赖会出现在应用程序运行并完成它的某些操作时。
+
+第 2 章 配置管理 P24 进行增量更改，满足我所在组织的所有合规性规定
+
+第 11 章 基础设施管理 P224  第 11 章 基础设施管理 P224
+准备部署环境的过程以及部署之后对环境的管理是本章的主要内容。然而为了能 够做到这一点，就要基于下面这些原则，用一个整体方法来管理所有基础设施。 ①   使用保存于版本控制库中的配置信息来指定基础设施所处的状态。  基础设施应该具有自治特性，即它应该自动地将自己设定为所需状态。  通过测试设备和监控手段，应该每时每刻都能掌握基础设施的实时状况。 什么不是管理基础设施的原则？编写新的通用基础管理脚本。
+
+2.2 章版本控制 P27  什么不被认为是实现配置管理这一目标的有效策略？始终将二进制文件和配置信息保存在一起。
+
+11.8.1 P254  cloud 安全和服务水平
+
+11.8.2 云中平台 P255 将应用部署到完全标准化的应用栈上，就意味着不需要担心测试环境、试运行 环境和生产环境的配置和维护，也不需要担心虚拟机映像的管理。最后一点尤其是革命性的。在本书中，用了大量的篇幅来讨论如何自动化你的部 署、测试和发布流程，以及如何搭建和管理测试和部署环境。云中的哪个平台特性最能实现自动部署？ Standardized stack
+
+10.5 紧急修复 P216  任何情况下，都不能破坏流程。紧急修复版本 也要走同样的构建、部署、测试和发布流程，与其他代码变更没什么区别。发布 RFc 作为紧急补丁并通知所有利益相关者。 然后根据 SLa 应用紧急补丁。P216
+
+---
+高效的 devOps 文化需要具备：高效沟通，共识与信任，人性化的员工配置和资源
+写一份项目章程很重要，一起写项目范围最好的理由是什么：确保所有团队对成功有着相同的定义
+衡量已找到程序错误的总数是跟踪项目质量最好的方法吗：全局范围内而非局部进行优化
+服务级别协议对专注于増加商业价值有所帮助
+
+---
+1. 场景：5 个月 h 后……，开发完成后才向类生产环境部署（考点，反模式）
+2. 在发布流程为软件发布创建一个可重复且可靠的过程。（考点，软件交付原则）
+3. dEVOPS 应该建立一个 Pull System、One Piece Flow 的 IT Super chain
+4. 建立 dEVOPS New Mind of all People，流程 One Piece Flow
+5. 场景：一家公司由于供应商的要求，只剩下 5 个月的时间建立 dEVOPS 的团队，他 们如何决定他们的迭代时间和频次？ 根据符合业务要求来确定
+6. dEVOPS 四个支柱 collaboration，Multiple People
+7. 要进行 dEVOPS 转型，coach Team 中的每一个人，建立 blameless 的文化 
+8. devOps 转型：沟通、同理心、人员和资源
+9. 场景：cEO 以前总是骂下面的人，现在采用了 dEVOPS 方式，情况有所好转，但是 没有达到理想效果，应该：Trust each Other，建立 blameless 文化
+10. 一个人抱怨另一个人，通过邮件到处宣扬对另一个人的不满，avoidance
+11. Gatekeeper 的职责：Security、compliance、Regulatory Requirements
+12. 浪费的类型：Extra Feature
+13. 在 dEVOPS 项目计划时，SLR 包含那些内容、安全、连续性等内容
+14. dEVOPS 项目开始时要做那些工作？Vision、Goal 等
+15. SOR 适用月那种 dEVOPS 方式，collaboration
+16. Obeya，信息共享，做决定
+17. auto Provisioning  auto maintenance
+18. VM 模板
+19. SLa 的重要性，业务连续性
+20. 在稳定没有时间的情况下进行：Happy Path 测试
+21. 场景：销售人员提出了一些列销售问题，这个用户故事符合 INVEST 原则？问选哪 一个：可测试性
+22. development Pipeline 对治理的作用
+23. 提交阶段需要做什么工作？
+24. 一个团队三个月进行一次新版本的部署，而且是按照模块开发和部署，因此他们认 为他们的采用的是 dEVOPS 的方法，选项问适合否
+25. 持续集成的优势 fewer bug、cheaper
+26. check In polices
+27. Run time build time
+28. 安全问题出现后，如何进行紧急变更
+29. 谁可以决定服务终止
+30. 数据库管理，此题是技术题，大概内容是要做一个回退脚本，且要保证原有数据不 能删除，但可能重构表内容。
+31. 不上云的理由，安全，SLa
+32. Standardized stack
+33. 手工发布软件的优势
+34. 手工测试的类型
+35. 场景：某人要提交有问题的代码，且振振有词讲到提交后可能通过变更进行更正。 
+36. 循环依赖
+37. Ensures performance (fast delivery) and conformance (to requirements
+38. 不要将生产数据库拿到测试环境
+39. JKK 100%质量覆盖
+40. 版本控制，巴黎，伦敦，悉尼，还有其他地方存在时差，如何进行版本控制
+41. 基础架构环境准备
+42. cross Function 的 6-8 人
+43. 不要把二进制文件放进构件库中
+44. Make such as an Executable
+45. Product Oriented
+46. Process Master 的职责，建立可视化看板，单件流等 
+47. 配置管理策略，增量，合规
+48. Increase speed without compromising quality
+
+

devopstest_v2.md

@@ -0,0 +1,283 @@
+# DevOps/CD/CI题目
+
+## 一、选择题（20）
+
+### 1. 验收测试的最佳选择?
+    a. Happy Path
+    b. 回归测试
+    c. alternate Path
+    d. Sad Path
+
+a. happy path 相当于做主流程
+
+### 2. 云计算的哪个特性能实现自动部署?
+    a.  标准栈
+    b.  规模化
+    c.  虚拟化
+    d.  通用性
+
+a. 标准栈使得自动部署成为可能
+
+### 3. 软件交付过程中，让整个过程自动化，并能够及时发现问题和修复问题，在此过程中,以下实践不是反模式选项是：
+    a，要求一份详尽文档，该文档描述了每个步骤中容易出错的地方
+    b，开发完成后才向类生产环境部署
+    c，提前频繁的做让你感到痛苦的事
+    d，手工进行生产环境的配置
+
+c. 痛苦的事情频繁做
+
+### 4. 良好的配置管理过程，是实现开发和部署过程可控和可重复的基础，以下哪个内容不是良好配置管理策略：
+    a. 能够再现所需的任何环境。
+    b. 为了达到系统运行稳定的目标，固化配置，任何修改都做登记。
+    c. 能够追踪某个具体环境的某次修改，并能够追溯修改源，以及什么时间谁做了修改。
+    d. 增量式修改，并可将修改部署到任意一种环境中。
+
+b. 不是敏捷策略。影响迭代。
+
+### 5. 每个应用程序都依赖于软件、硬件、基础设施等才可以正常工作，这些内容称作应用程序的环境，环境管理与配置管理同样重要。以下哪种不是良好的环境管理实践：
+    a. 环境管理的关键是通过一个自动化过程来创建环境。
+    b. 因为环境管理的重要性，一旦系统出问题，派遣资深专家花费不确定的时间来找到问题，并修复它。
+    c. 修复某个环境可能需要大量时间，因此，最好在可预见的时间里重建环境，并将其恢复到某个已知的正常状态。
+    d. 创建一个类生产环境，配置问题可在早期测试中发现。
+
+b. 自动化、简单化、可量产、可重现，不是依赖资深专家
+
+### 6.  公司打算构建一条部署流水线，公司领导希望实现频繁发布。 有团队成员认为：这条部署流水线最重要的是自动化。团队首先要让它自动化起来。 这种说法对吗？
+    a.  是的，这是正确的。部署流水线自动化是提升效率的最重要因素。
+    b.  是的，这是正确的。关注自动化部署流水线的创建，克服之后可能遇到的潜在问题。
+    c.  不，这是错误的。完成单件流及一个可靠的部署流程是优先级最高的任务。该流程的自动化可以暂缓实施。
+    d.  不，这是错误的。首先应当自动化的是测试流程而非部署流水线。
+
+c, 无论何时，所有部署流水线首先应当是单件流程的部署流水线，无需自动化就可高效运行。一旦该流水线稳定确立，就有机会选择可行的流程实施自动化。但是，构建稳定的部署流水线永远比自动化更重要。
+
+### 7. 有很多方法可以使组织趋向成熟，下列哪种方法不会使你的devOps组织更趋成熟？
+    a. 明确定义目标定和里程碑，帮助团队成员判断其日常活动是否有价值。
+    b. 明确定义流程，支持并促使团队成员逐日改进流程。
+    c. 对会议的所有内容进行记录，使你的团队成员可以很方便的了解到每次沟通的内容信息。
+    d. 监控并记录每天的活动，以找出小范围内每天取得的进步并予以赞扬。
+
+c, 这无助于devOps组织的成熟。是否要对会议进行全程记录并再次审查，并没有严格的要求。有必要记录达成共识的内容，而不是记录整 场会议。
+
+### 8.  你认为自己的开发团队是一支真正的团队。 你觉得有什么确切的特征表明这是一支团队而不只是一个小组呢？
+    a.	该团队遵守在团队会议中共同制定的规则。
+    b.	团队召开自己主持的高效会议。
+    c.	团队以稳定的工作节奏，朝着共同的目标推进。
+    d.	该团队通过质询负责某项工作的团队成员的方式来解决问题。
+
+d 一支真正的团队能够维持稳定的工作节奏，并能够始终向着共同的目标努力。
+
+### 9.  为采用整体方法处理所有基础设施，应当遵循哪两条原则?
+    a.
+      1	你的基础设施应具备的状态需要通过变更控制配置来确定。
+      2	你应当通过监控与事件管理，及时了解基础设施的准确状态。
+    b.
+      1	需要通过变更控制配置来确定你的基础设施应具备的状态。
+      2	你应当通过仪器仪表及事件管理，始终了解基础设施的确切状态。
+    c.
+      1	你的基础设施应具备的状态需要通过版本控制配置来确定。
+      2	你应当通过当前事件与事件管理，始终了解基础设施的确切状态。
+    d.
+      1	你的基础设施应具备的状态需要通过版本控制配置来确定。
+      2	你应当通过仪表盘与监控始终了解基础设施的确切状态。
+
+d, 为采用整体方法处理所有基础设施，应当遵循这两条核心原则。
+
+### 10.  在敏捷和devops中吸收了很多精益核心概念。实施devOps时，将精益的相关概念应用在devOps过程中，有助于成功实施devops。 在此过程中，精益管理的哪些原则或实践方法最有效?
+    a. Kaizen(专有词，意为小的、不花钱的持续改善)
+    b. 5S - 整理（SHIRI）、整顿（SEITON）、清扫（SEISO）、清洁（SEIKETSU）、素养（SHITSUKE）
+    c. Obeya系统(可视化管理)
+    d. 单件流与质量检查
+
+d, 创建一个可行的、单件部署流水线将有助于成功实施devOps。devOps中最重要的工作在于构建从开发部门到运维部门的上游流程，尤其是针对单一部署流水线。质量检查（JKK）是能够达成这一目标的最有效的工作行为。
+
+### 11.  持续集成不会单独的帮你修复构建过程，在中后期开展持续集成，意味着在构建过程需要耗费大量工作。 为了使持续集成更高效，早期阶段，一般不会涉及的工作是？
+    a. 频繁提交代码到版本控制库
+    b. 创建分支，并尽早提交代码到分支
+    c. 创建自动化测试套件
+    d. 保持较短的构建和测试过程
+
+b. 应提交到主干，分支容易破坏即时集成
+持续交付 P46
+
+### 12.  关于版本控制，以下说法不正确的是？
+    a. 源代码必须纳入版本控制。
+    b. 配置信息必须纳入版本控制。
+    c. 为了加快发布周期和提高软件质量，将编译器或其他相关工具的二进制镜像纳入版本控制。
+    d. 为了加速打包，将源代码编译后的二进制文件纳入版本控制。
+
+d. 不推荐
+  1. 比较大，
+  2. 每次重新构建都会重新生成二进制文件，无必要
+
+### 13. 一个开发团队对devOps感兴趣。他们主要感兴趣的对象是持续集成（cI）。他们目前开发并维护着三种主要解决方案及四种次要解决方案。他们采用Scrum实践方法。每次冲刺都需要四周时间，平均每十天到十五天对测试环境都有一次提交发布，平均每个月对生产环境有一次发布。他们想为管理层制定一个定性的商业论证，来支持他们为创建持续集成实践模式而付出的投资与努力。 持续集成有哪些显性收益对该商业论证最为有利？
+    a. 每天对测试环境进行一次部署能极大的提高商业效益并且大大缩减开发成本。
+    b. 这有助于提升团队精神。由于公司已经在使用Scrum，持续集成将为公司业务带来显著的益处。
+    c. 它通过更好的集成测试提高了业务稳定性，同时维持发布速度以防止产生额外成本。
+    d. 在生产环境中，每天进行一次信息发布能够提升业务收益，并大大减少开发成本。
+
+d, 更快速的向生产环境发布是持续集成的一大主要益处，此外还包括更快速地发现故障以减少开发成本和故障修复成本。
+
+### 14.  关于使用脚本去构建和部署流程自动化，以下说法正确的是？
+    a. 每种环境采用一个脚本，并将其作为版本控制系统的一部分加以维护。
+    b. 不同环境使用不同的特定脚本，以解决环境之间的差异问题。
+    c. 不同环境采用同样的脚本，对特定的配置采用手动参数。
+    d. 采用同一脚本在不同环境中进行部署，并单独管理配置信息。
+
+d, 脚本应当保持一致，才能保证构建和交付流程得到有效测试。环境之间（如URI和IP等）的差异应当作为配置管理流程的一部分予以处理。
+
+### 15. 当有运维侧变更时，运维部门告知开发部门的最佳时间是何时？
+    a. 无需告知开发团队。运维侧的变更仅运维团队知晓即可。
+    b. 立刻执行。应当尽快通知开发部门。
+    c. 次日早晨的Scrum会议中。
+    d. 当运维团队已经完成验收测试时。
+
+b, 应当立即告知开发部门，让他们能够预见潜在的风险和问题。
+
+### 16. 考虑对基本部署流水线进行具体解析。 哪个阶段表明该系统在功能性与非功能性层面均发挥作用？
+    a. 自动化验收测试
+    b. 构建与单元测试
+    c. 手动验收测试
+    d. 版本控制
+
+a. 自动化验收测试阶段表明，系统在功能性与非功能性层面上工作正常，在行为上它能满足用户的需求和客户的规格要求。
+
+### 17. 开发团队当前在测试中遇到诸多挑战。目前他们使用人工验收测试流程。 开发者认为他们所创建的单元测试是十分周密的，可以避免回退。 在每次发布时，开发团队都需要花费100万在人工验收测试环节。 领导层要求开发团队实施自动化验收测试，以降低测试的总成本并尽可能减少引入生产环境中的代码缺陷数量和回退次数。 在依照自动化需求确定应用程序的验收标准时，应当遵循什么原则？
+    a. agile（敏捷）原则
+    b. aTaM（架构权衡分析法）原则
+    c. dIVEST原则
+    d. INVEST原则
+
+d, 验收测试源自验收标准，因此你的应用程序的验收标准的制定应当考虑自动化因素，遵循INVEST原则；
+  - Independent(独立性)
+  - Negotiable(可协商)
+  - Valuable(有价值)
+  - Estimatable(可估计)
+  - Small(小而少)
+  - Testable(可测试)
+
+### 18. 自动化测试是高效软件发布和实现持续交付的基础，以下那一类测试不宜全面自动化。
+    a. 容量测试
+    b. GUI测试
+    c. 单元测试
+    d. 探索性测试
+
+d. 探索性测试一般需结合人工测试
+
+### 19.  公司正在使用devOps。该公司实施了持续部署，并具备高度自动化验收测试和每日向生产部交付新软件的稳定部署流水线。公司有一个巨大的数据库及众多用户。该公司具备全面可靠的容量测试策略。由于该公司环境广大而复杂，随着每个新版本的发布，生产部就会出现一些小故障。 什么策略能够最有效地帮助该公司预防这些故障？
+    a. 采用金丝雀发布
+    b. 自动化容量测试
+    c. 降低交付率
+    d. 采用蓝绿部署
+
+a.
+  - 金丝雀发布:
+      包括向生产服务商中的一小部分推出新版本的应用程序，以快速收集反馈。这能够快速发现新版本中出现的所有问题，而不会对大多数用户产生影响，因为工作量是逐渐增长的；同时这一做法还能确定响应时间及其他工作表现衡量标准，减少新版本发布的风险，并帮助尽快发现与修复漏洞。
+  - 蓝绿部署
+      需要大量资源，因而在该情境中代价高昂。此外，若需要回退，在大型数据库中采用这一策略可能导致故障或只读情况发生。另外，这也无助于容量测试效率的提高。
+
+### 20.  公司正在尝试转变，并开始使用devOps的方式开展工作。你的团队也在经历这一转变。 你正在参与讨论代码提交阶段的最佳实践。 某同事说：“当某一构建遭到破坏且无人担责时，我们应当找出造成破坏的人并要求他们展开工作，以保证他们能修复这一构建。” 这样做合适吗？
+    a. 是的。只有破坏构建的人才能够修复它，因此你应当找到负责人，即使这样可能会让人感觉不舒服。
+    b. 是的。你应当始终为破坏构建负责。如果你不负责，你的同事将可能强制执行这项规定。
+    c. 不，devOps环境中不存在追责。若同事不承担责任，不要强迫他们。
+    d. 不，你应当首先修复构建。然后抽出时间，确定相关负责人并进行处罚。
+
+c, Devops文化不提倡强迫任何人做任何事。犯错是可以接受的。团队成员共同协作以克服各种错误或挑战。
+
+
+## 二、简答题（5）
+### 1. 简述devops能带来哪些效果？
+    - 快速发布
+    - 降低成本
+    - 持续反馈，提高软件质量
+    - 更关注业务产出，给客户带来价值
+
+### 2. 每个系统都会遇到这种情况：发现一个严重缺陷，必须尽快修复。简述紧急变更过程?
+    需牢记：任何情况下，都不能破坏流程，紧急修复版本同样走构建、部署、测试、发布流程，与其他代码变更没有区别。
+      - 申请变更(Request for change,RFc)
+      - 分析影响
+      - 通知利益相关方
+
+### 3. devops文化转变包含哪些?
+    - 高效
+    - 亲和
+    - 协作
+    - 高度信任
+    - 同理心
+    - 非谴责
+    - 单件流
+
+### 4. 持续集成不光是一些工具组合，更是一种实践，它的有效性也依赖于团队纪律。简述cI(持续集成)的好处，及为了实现持续集成目标，有哪些良好的实践?
+    好处：
+      - 软件在任何时候可工作
+      - 更少的bug
+      - 更低的成本
+      - 更快发现bug
+    良好实践或纪律：
+      - 构建失败后不要向版本库提交新代码, 确保软件一直可工作
+      - 本地构建并运行提交测试，测试通过才继续工作
+      - 不要将失败的构建注释掉
+      - 为自己导致的问题负责
+      - 所有人为质量负责
+      ...
+
+### 5.  在自动化运维中，要实现基础设施和应用程序的监控策略，通常要考虑哪些方面内容或从哪些方面着手？
+      - 采集数据，软硬件运行情况，健康度，统计信息等, 通过SNMP/TR069等
+      - 记录日志，解析、分析、统计日志文件，并关注日志等级
+      - 建立信息展示板(dashborad),可视化
+      - 建立自动通知/告警机制
+
+## 三、论述题（2）
+### 1. 在软件发布过程共，我们常常看到测试、运维、开发团队协作不畅导致的流程受阻，部署流水线从端到端来贯穿流程，实现自动化构建、部署、测试和发布。公司推进敏捷/devops，请结合实践，论述如何构建一套部署流水线，以及这套部署流水线如何在实践中更好的实现持续交付。
+
+#### 内容要点： 结合实践来阐述
+    1. 部署流水线流程
+          - 提交,版本控制库
+          - 自动构建和单元测试（可能涉及自动配置管理）
+          - 部署二进制包
+          - 自动化验收测试(一般做冒烟测试，也可能包括自动化容量、安全等非功能性测试)
+
+          - 运维一键部署到生产环境（容器化,生产环境配置，部署二进制包）
+       流程的起点是开发人员向版本控制库提交代码，流水线对提交作出响应，触发流水线的一个实例，编译代码，运行单元测试，执行代码分析，创建软件的二进制包；如果所有单元测试通过，代码符合标准，完成软件打包；之后触发自动化验收。
+
+    2. 构建流水线过程
+          - 对价值流建模并创建简单的可工作框架（比如流行的jenkins）
+          - 将构建和部署流程自动化
+          - 将单元测试和代码分析自动化
+          - 将功能（验收）测试自动化
+          - 将发布自动化
+
+    3. 一些良好实践
+          - 部署流水线的成功的关键之一是各个环节能够尽快得到反馈
+          - 项目较大情况下，全量或回归测试可能耗费大量的时间，可能打断持续集成效率，在流水线中往往只做冒烟测试，通常要在一两个小时内完成该过程。
+          - 确保生产中部署的包与流水线生成的二进制包是同一个，或者对包做HaSH验证。重新创建二进制包将带来不一致风险。
+          - 如果某个环节失败，应停止整个流水线。整个团队对失败负责。
+          - 象其他交付的应用一样，对部署流水线进行增量式实现，不断改善和重构。
+          - 让每个环节可视化，让大家能够清晰的看到哪个环节有什么问题。
+
+
+参考<持续交付>第五章相关内容
+
+### 2.  一个电信级应用部署在云上，随着业务不断演进，系统用户和数据量不断增加，云资源的稳定性和系统的复杂性带来的系统服务中断的风险越来越大，系统中断的影响也随之增加。请结合实践，论述从哪些方面来提升系统可用性或提升系统容灾能力。 从以下要点结合实践展开论述：
+
+#### 从以下角度结合应用进行分析：
+    架构手段：
+        - 冷、热备份，心跳检测保活
+              如通过LVS、haproxy、keepalive等方式
+        - 集群 & 负载均衡 & 分布式
+              负载均衡架构是多个服务做一堆同类的事情，每件事情相互独立；
+              分布式的架构则是将一件复杂的事情分解出多个部份，由多个服务去做，再通过架构实现多个分解事情处理结果的合并。
+        - 多中心，异地异机房，涉及负载分担和数据同步等问题的考虑
+        - 纵向扩容，如加服务器资源，换性能更强的服务器提升服务能力
+        - 横向扩容，对业务、数据库、区域等进行划分
+        - 业务服务的拆分
+        - 数据库的读写分离
+        ...
+
+    运维手段：
+        - 虚拟化、容器化
+        - 监控手段，发现机制和加速处理机制等
+        - 演练和一些馄饨学工具故障模拟
+        - 自动化运维，监控预警等手段
+        - 应急预案
+        ...
+

digit.md

@@ -0,0 +1,73 @@
+
+## 技术保障部数字化转型报告
+
+History
+
+时间 | 内容 | 作者
+--- | --- | ---
+2019/9/8 | 初稿 | CG
+2019/9/9 | 增加不同团队数字化转型输出 | CG
+
+---
+
+### 技术保障部数字化转型怎么转，先弄清楚为什么和怎么做问题
+
+转型前事务驱动或流程驱动工作，事务可能是一揽子计划，也可能是一些零散的任务，事务驱动就是完成计划或任务；流程驱动是业务流程固化，作业是在一系列的流程和规则下完成，流程驱动是原来信息化的核心内容。数字化则要求数字驱动，数字能够准确反映当前不同切面的健康状况，进而推动工作生产改善。
+
+**数字化转型要点：**
+
+> -	数字驱动
+<br>数字化转型要从事务、流程驱动转变为数字驱动。
+> -	量化、分析
+<br>数据可能是海量和无序的，通过量化能掌握进度，通过分析发现问题, 进而开展精准改进。
+> -	敏捷，速度
+<br>数字化最终为了能够更好服务客户或服务生产，数字能反映当下，因此，数字本身就有敏捷的特点，要求组织能够快速跟进。也即敏捷型组织才能匹配数字化转型的要求。
+> -	迭代，连续性
+<br>事务或流程驱动大多属于计划性或外部驱动，数字却反映持续的变化，数字驱动推动快速迭代，从而持续改进，这是敏捷性组织的要求， 非敏捷组织跟不上数字化要求。 
+> -	自动化
+<br>自动化是数字化转型的基本要求，在自动化基础上，才具备敏捷的要求。
+> -	共享、协作
+<br>原来信息化下，各部门、各系统之间往往是独立的，各部分都是信息孤岛，功能也是垂直烟囱式的发展，新的项目就是一条新的烟囱，这种状况数据都是大象的一只腿，不是全貌，数字化很难实现，数字化要求数据的流动，数据是互相参照，形成画像，这样分析及结果才有价值，才能指导生产，驱动效率提升。
+> -	安全
+<br>数据成为生产资料，数据发挥更大价值，也承担更多风险，数据开放下的安全保障尤其重要。
+
+**具体到运维支撑测试数字化转型工作**
+- 支撑工作就是典型的事务驱动，这个事务就是故障、投诉或项目支撑工作。数字化转型有必要梳理和设立一些数字检视点，通过这些检视点数据分析，判断健康度，及早预警，早于投诉发现问题，解决问题。在数据的采集、分析由运维团队介入，引入自动化手段，甚至可以进行健康度打分。监控人员从原来主动定时查看，增加邮件、短信等推送方式的告警接受和预处理。 对于项目支撑，考虑到项目的个性化，零散化，是不是不能开展数字化转型呢？关键在于标准化基础上的数字化支撑， 标准化便于形成统一文通，统一FAQ口径，还可自动化处理，避免疲于应付客户要求，进而实现更多的远程支撑，减少现场支撑量，降低成本。
+
+- 运维工作的数字化转型，主要要转变被动的“救火式”运维模式，这种模式出现问题后着手处理，被问题牵着鼻子走，运维人员看似忙碌，效率却不一定高，运维质量也很难提高，运维开发如果被困在这种低质量的应付事务中，就很难腾出精力从更高的层面优化系统，避免问题于未发生前，这种被动处理方式，用户满意度必定也会下降。 转变这种模式，要有一套方法论来指引，如devops，并辅之以相应的工具手段， 用拥抱变化的态度来匹配敏捷性组织的要求。 <br><br> devops敏捷和快速迭代意味着更频繁的发布和部署， 运维自动化和研运测的全流程贯通是内生要求， 此外， 响应变化和快速迭代也要求运维、测试、支撑团队成员能够快速了解和跟进项目现状， 确保测试、上线、支撑顺畅不脱节，所以devops重视Dev开发与Ops运维之间沟通合作，并需让它成为公司文化惯例，当然，沟通的形式多样，会议或面对面是一种，数字化转型更要求采用数字化手段来确保dev到ops的消息流转，就避免如修改配置运维不知悉导致部署后系统不能运行，更新的需求没有同步到测试导致新用例未覆盖新需求等问题。目前已全面使用自动化运维平台实现服务器、应用、业务的统一监控纳管，及进行环境部署、上线、监控、告警。
+
+- 测试工作数字化，自动化测试首次成本会高于手工测试，但自动化测试的收益是随着测试次数和重复次数的增加而相应增加，此外自动化测试还存在维护工具和自动化用例编写的维护成本，数字化转型要用数据来充分分析自动化测试节约的成本情况，成果可量化，过程可量化。测试工作像来料加工厂， 工作量的峰谷特性明显， 管理上拟引入OKR法来推进团队工作， 结果产出可量化， 目标可追踪， 更好推进组织绩效 。
+
+- 数字化甚至智能化对工具的要求也随之提高，开源社区快速发展，工具可选很多， 但工具应自主可控， 应具有开放性， 自主可控才能微创新以更好服务于业务， 工具应与业务结合才有意义， 才有比较优势。 支撑运维都应懂业务， 又懂技术。 自主可控并不是自己造轮子， 但要能够整合这些工具形成有机整体服务于业务， 而不是烟囱式的， 这不符合数字化的自动化、信息流动和敏捷的特点， 比如自动化测试大家都在用selenium，是成熟框架， 但在此基础上结合业务进行脚本封装就是降低手工过程，提供复用效率的手段， 把selenium内嵌在平台中，打通测试项目管理、测试用例管理、GUI录制并脚本化、自动化用例编写、自动化脚本的参数化、测试报告输出和统计等能力， 甚至结合postman等接口测试工具， 这些需要自己来整合。作为测试团队，要考虑要更多，比如怎么做安全测试？ 安全测试完成后如何自动化修复漏洞？ 怎么做性能测试？ 目前安全测试还独立在做， 还没有办法嵌入到自动化测试平台中， 性能测试已经能够在自动化测试平台中进行， 但总体使用还比较少， 这些部分在数字化转型中要加强。 
+
+- 数字化转型最终是服务于客户体验的持续改进， 技术保障部不面向最终客户需求， 但不同团队输出成果的使用方便是客户， 支撑目的是解决用户使用问题， 用户问题的量化是有的，但数字化的方式的统计分析还是不够， 比如前述的跟用例的对比， 检视点数据/账单对比分析等需要加强。自动化测试平台的使用对象是自动化测试团队，自动化测试团队就需要定期提供量化的反馈给运维开发团队。 运维部署上线服务于devops，上线情况应量化的反馈给dev。
+<br>
+
+### 技术保障部数字化转型输出
+<br>
+
+功能块 | 转型要点 | 数字化输出
+---- | ---- | ----
+支撑 | 标准化，支撑事务形成标准化，不同阶段量化输入输出、介入方式和程度 | 安审支撑标准化文档流程
+支撑 | 数字化监控,对日常监控指标进行提炼，重点指标邮件短信等方式即时通知到人 |  分等级、分类型监控指标报告
+支撑 | 数字化检视点，梳理业务流程，插入检视点自动对接口数据和消费情况进行比对核查，确保一致，不一致提供告警 | 数据接口报告（如短信、审计、话单...）
+支撑 | 数字化故障预防，梳理历史报障、投诉工单，采用数字化手段，变被动人工保障为主动自动巡检 | 故障历史数字化报告（包含改进点梳理）
+运维 | 敏捷，工具、方法论 | 体现敏捷思维工具报告（体现工具名称、选型、作用、使用体验）
+运维 | 运维服务质量数字化 | 
+运维 | 高可用性指标，梳理故障点，部署HA | 单点数字化
+运维 | 协助沟通，会议沟通外通过数字化手段粘合dev和ops的信息流动 | *落实动作*
+运维 | 工具的共享开放程度，工具被外部使用情况 | 自动化运维、自动化测试平台使用情况报告
+运维 | 自动化运维，服务器、应用、业务统一纳管，故障隔离与自愈 | 自动化运维数字化报告 （服务器、应用、业务情况报告）
+运维 | 数据可视化，网络可视化 | 自动化运维数字化报告
+测试 | 试行OKR | *落实动作*
+测试 | 自动化用例量，自动化用例覆盖率 | 测试数字化报告 （按项目，进度、自动化覆盖率）
+测试 | 全面自动化及自动化成本量化测算 | 测试数字化报告 （成本测算）
+测试 | 报障投诉与测试的关联分析 | 测试数字化报告
+测试 | 自动化测试工具使用对比打分反馈，推动工具改进 | 自动化测试工具、平台选型报告
+测试 | 项目自动化性能测试清单、比例 | 测试数字化报告
+安全 | 安全内外部工作量化，安扫及修复情况量化，分项目安全保障梳理 | 安全数字化报告
+安全 | 安全工具选型研究 | 安全数字化报告
+安全 | 安全自动化，安全嵌入测试中 | 安全数字化报告
+<br>
+
+

digit_dd.md

@@ -0,0 +1,119 @@
+
+## 技术保障部数字化转型报告
+
+History
+
+时间 | 内容 | 作者
+--- | --- | ---
+2019/9/8 | 初稿 | CG
+2019/9/9 | 增加不同团队数字化转型输出 | CG
+
+---
+
+### 技术保障部数字化转型怎么转，先弄清楚为什么和怎么做问题
+
+转型前事务驱动或流程驱动工作，事务可能是一揽子计划，也可能是一些零散的任务，事务驱动就是完成计划或任务；流程驱动是业务流程固化，作业是在一系列的流程和规则下完成，流程驱动是原来信息化的核心内容。数字化则要求数字驱动，数字能够准确反映当前不同切面的健康状况，进而推动工作生产改善。
+
+**结合支撑运维测试的工作来谈谈数字化转型的抓手：**
+
+> -	数字驱动
+<br>数字化转型要从事务、流程驱动转变为数字驱动。
+> -	量化、分析
+<br>数据可能是海量和无序的，通过量化能掌握进度，通过分析发现问题, 进而开展精准改进。
+> -	敏捷，速度
+<br>数字化最终为了能够更好服务客户或服务生产，数字能反映当下，因此，数字本身就有敏捷的特点，要求组织能够快速跟进。也即敏捷型组织才能匹配数字化转型的要求。
+> -	迭代，连续性
+<br>事务或流程驱动大多属于计划性或外部驱动，数字却反映持续的变化，数字驱动推动快速迭代，从而持续改进，这是敏捷性组织的要求， 非敏捷组织跟不上数字化要求。 
+> -	自动化
+<br>自动化是数字化转型的基本要求，在自动化基础上，才具备敏捷的要求。
+> -	共享、协作
+<br>原来信息化下，各部门、各系统之间往往是独立的，各部分都是信息孤岛，功能也是垂直烟囱式的发展，新的项目就是一条新的烟囱，这种状况数据都是大象的一只腿，不是全貌，数字化很难实现，数字化要求数据的流动，数据是互相参照，形成画像，这样分析及结果才有价值，才能指导生产，驱动效率提升。
+> -	安全
+<br>数据成为生产资料，数据发挥更大价值，也承担更多风险，数据开放下的安全保障尤其重要。
+
+**具体到运维支撑测试数字化转型工作如下**
+- 支撑工作就是典型的事务驱动，这个事务就是故障、投诉或项目支撑工作。数字化转型有必要梳理和设立一些数字检视点，通过这些检视点数据分析，判断健康度，及早预警，早于投诉发现问题，解决问题。在数据的采集、分析由运维团队介入，引入自动化手段，甚至可以进行健康度打分。监控人员从原来主动定时查看，增加邮件、短信等推送方式的告警接受和预处理。 对于项目支撑，考虑到项目的个性化，零散化，是不是不能开展数字化转型呢？关键在于标准化基础上的数字化支撑， 标准化便于形成统一文通，统一FAQ口径，还可自动化处理，避免疲于应付客户要求，进而实现更多的远程支撑，减少现场支撑量，降低成本。
+
+- 运维工作的数字化转型，主要要转变被动的“救火式”运维模式，这种模式出现问题后着手处理，被问题牵着鼻子走，运维人员看似忙碌，效率却不一定高，运维质量也很难提高，运维开发如果被困在这种低质量的应付事务中，就很难腾出精力从更高的层面优化系统，避免问题于未发生前，这种被动处理方式，用户满意度必定也会下降。 转变这种模式，要有一套方法论来指引，如devops，并辅之以相应的工具手段， 用拥抱变化的态度来匹配敏捷性组织的要求。 <br><br> devops敏捷和快速迭代意味着更频繁的发布和部署， 运维自动化和研运测的全流程贯通是内生要求， 此外， 响应变化和快速迭代也要求运维、测试、支撑团队成员能够快速了解和跟进项目现状， 确保测试、上线、支撑顺畅不脱节，所以devops重视Dev开发与Ops运维之间沟通合作，并需让它成为公司文化惯例，当然，沟通的形式多样，会议或面对面是一种，数字化转型更要求采用数字化手段来确保dev到ops的消息流转，就避免如修改配置运维不知悉导致部署后系统不能运行，更新的需求没有同步到测试导致新用例未覆盖新需求等问题。目前已全面使用自动化运维平台实现服务器、应用、业务的统一监控纳管，及进行环境部署、上线、监控、告警。
+
+- 测试工作数字化，自动化测试首次成本会高于手工测试，但自动化测试的收益是随着测试次数和重复次数的增加而相应增加，此外自动化测试还存在维护工具和自动化用例编写的维护成本，数字化转型要用数据来充分分析自动化测试节约的成本情况，成果可量化，过程可量化。测试工作像来料加工厂， 工作量的峰谷特性明显， 管理上拟引入OKR法来推进团队工作， 结果产出可量化， 目标可追踪， 更好推进组织绩效 。
+
+- 数字化甚至智能化对工具的要求也随之提高，开源社区快速发展，工具可选很多， 但工具应自主可控， 应具有开放性， 自主可控才能微创新以更好服务于业务， 工具应与业务结合才有意义， 才有比较优势。 支撑运维都应懂业务， 又懂技术。 自主可控并不是自己造轮子， 但要能够整合这些工具形成有机整体服务于业务， 而不是烟囱式的， 这不符合数字化的自动化、信息流动和敏捷的特点， 比如自动化测试大家都在用selenium，是成熟框架， 但在此基础上结合业务进行脚本封装就是降低手工过程，提供复用效率的手段， 把selenium内嵌在平台中，打通测试项目管理、测试用例管理、GUI录制并脚本化、自动化用例编写、自动化脚本的参数化、测试报告输出和统计等能力， 甚至结合postman等接口测试工具， 这些需要自己来整合。作为测试团队，要考虑要更多，比如怎么做安全测试？ 安全测试完成后如何自动化修复漏洞？ 怎么做性能测试？ 目前安全测试还独立在做， 还没有办法嵌入到自动化测试平台中， 性能测试已经能够在自动化测试平台中进行， 但总体使用还比较少， 这些部分在数字化转型中要加强。 
+
+- 数字化转型最终是服务于客户体验的持续改进， 技术保障部不面向最终客户需求， 但不同团队输出成果的使用方便是客户， 支撑目的是解决用户使用问题， 用户问题的量化是有的，但数字化的方式的统计分析还是不够， 比如前述的跟用例的对比， 检视点数据/账单对比分析等需要加强。自动化测试平台的使用对象是自动化测试团队，自动化测试团队就需要定期提供量化的反馈给运维开发团队。 运维部署上线服务于devops，上线情况应量化的反馈给dev。
+<br>
+
+~~### 技术保障部数字化转型思路一览表~~
+<br>
+
+功能块 | 转型要点 | 数字化标准(近期补充中)
+---- | ---- | ----
+支撑 | 标准化，支撑事务形成标准化，不同阶段量化输入输出、介入方式和程度 | 
+支撑 | 数字化监控,对日常监控指标进行提炼，重点指标邮件短信等方式即时通知到人 | 
+支撑 | 数字化检视点，梳理业务流程，插入检视点自动对接口数据和消费情况进行比对核查，确保一致，不一致提供告警 | 
+支撑 | 数字化故障预防，梳理历史报障、投诉工单，采用数字化手段，变被动人工保障为主动自动巡检 | 
+运维 | 敏捷，工具、方法论 | 
+运维 | 服务质量数字化 | 
+运维 | 高可用性指标，梳理故障点，部署HA | 
+运维 | 协助沟通，会议沟通外通过数字化手段粘合dev和ops的信息流动 | 
+运维 | 工具的共享开放程度，工具被外部使用情况 |
+运维 | 自动化运维，服务器、应用、业务统一纳管，故障隔离与自愈 |
+运维 | 数据可视化，网络可视化 |
+测试 | 试行OKR | 
+测试 | 全面自动化及自动化成本量化测算 | 
+测试 | 报障投诉与测试的关联分析 | 
+测试 | 自动化测试工具使用对比打分反馈，推动工具改进 | 
+测试 | 自动化用例量，自动化用例覆盖率 |
+安全 | 安全自动化 |
+<br>
+
+### 技术保障部数字化转型周报模板(2019/8/31~2019/9/6)
+<br>
+
+功能块 | 工作内容 | 数字化转型体现
+--- | --- | ---
+运维 | 虚拟化容器化一键部署前端开发 | 一键部署，加速部署效率
+运维 | 网络拓扑图的网关层/主机层/服务层实现采集绘制 | 网络可视化，完成80%
+运维 | 视频云部署<br> 金华、宁波已完成<br>宁波完成新增3个管理平台部署，进行基线和漏洞的修复,预计9/14前可完成修复后转noc进行公网的开通<br>衢州资源发起申请，落地后2天内完成部署 | 一键部署，效率提升
+运维 | 容器化方案与研发联合办公1周 | devops要求dev & ops沟通
+运维 | 分析云、接入服务等上线 | >20次
+测试 | SDN网关测试纳入自动化测试平台 | 接口自动化用例数43个, 敏捷、自动化
+测试 | 视频云平台生产环境接口测试 | 接口72个，自动化用例481个，BUG 20个
+测试 | 能力开放平台第四轮测试，beta环境改用Docker部署，9/14前输出报告 | 232个用例，通过122个，失败26个，阻塞8个<br><br>测试部署效率提升
+测试 | 自动化测试平台接口用例参数化，更加灵活，自动化脚本编写效率提升 | 测试效率提升
+测试 | 自动化测试平台执行机效率优化，9/11~14 | 敏捷
+测试 | 海南IPV6测试 | 数字化程度低，需改进
+测试 | 智慧楼宇项目测试，9/5测试团队与拓展部沟通，了解业务和需求，及早接入 | 开展自动化测试
+支撑 | 安审支撑标准化 | 便于远程支撑，效率提升，节省人力成本
+安全 | 物联网tomcat类基线修复完毕,nginx完成7组基线修复 | 
+安全 | 集团网信安中期检查，集约化工作检查整改，各种报表 | 
+<br>
+
+### 技术保障部数字化转型输出
+<br>
+
+功能块 | 转型要点 | 数字化输出
+---- | ---- | ----
+支撑 | 标准化，支撑事务形成标准化，不同阶段量化输入输出、介入方式和程度 | 安审支撑标准化文档流程
+支撑 | 数字化监控,对日常监控指标进行提炼，重点指标邮件短信等方式即时通知到人 |  分等级、分类型监控指标报告
+支撑 | 数字化检视点，梳理业务流程，插入检视点自动对接口数据和消费情况进行比对核查，确保一致，不一致提供告警 | 数据接口报告（如短信、审计、话单...）
+支撑 | 数字化故障预防，梳理历史报障、投诉工单，采用数字化手段，变被动人工保障为主动自动巡检 | 故障历史数字化报告（包含改进点梳理）
+运维 | 敏捷，工具、方法论 | 体现敏捷思维工具报告（体现工具名称、选型、作用、使用体验）
+运维 | 运维服务质量数字化 | 
+运维 | 高可用性指标，梳理故障点，部署HA | 单点数字化
+运维 | 协助沟通，会议沟通外通过数字化手段粘合dev和ops的信息流动 | *落实动作*
+运维 | 工具的共享开放程度，工具被外部使用情况 | 自动化运维、自动化测试平台使用情况报告
+运维 | 自动化运维，服务器、应用、业务统一纳管，故障隔离与自愈 | 自动化运维数字化报告 （服务器、应用、业务情况报告）
+运维 | 数据可视化，网络可视化 | 自动化运维数字化报告
+测试 | 试行OKR | *落实动作*
+测试 | 自动化用例量，自动化用例覆盖率 | 测试数字化报告 （按项目，进度、自动化覆盖率）
+测试 | 全面自动化及自动化成本量化测算 | 测试数字化报告 （成本测算）
+测试 | 报障投诉与测试的关联分析 | 测试数字化报告
+测试 | 自动化测试工具使用对比打分反馈，推动工具改进 | 自动化测试工具、平台选型报告
+测试 | 项目自动化性能测试清单、比例 | 测试数字化报告
+安全 | 安全内外部工作量化，安扫及修复情况量化，分项目安全保障梳理 | 安全数字化报告
+安全 | 安全工具选型研究 | 安全数字化报告
+安全 | 安全自动化，安全嵌入测试中 | 安全数字化报告
+<br>
+
+

disaster_recovery.md

@@ -0,0 +1,43 @@
+
+# 容灾
+
+域内HA,参考[HA架构](hanote.md)
+
+### 异地容灾
+
+- 目的 :grey_question:
+- 目标 :grey_question:
+- 怎么做 :grey_question:
+- 应用场景 :grey_question:
+- 访问耗时问题 :grey_question:
+- 扩展能力 :grey_question:
+- 分布式事务XA问题 :grey_question:
+- 架构 :grey_question:
+
+热备和多活用户不感知流量切换
+热备是主用负载，多活是多点负载，负载分担
+
+
+### 故障演练
+   
+   混沌工程
+   chaos monkey
+   monkeyking
+
+服务注册中心
+
+## TBC :clock1::clock2::clock3::clock4::clock5::clock6::clock7::clock8::clock9::clock10:
+
+* references
+1. [混沌工程工具ChaosBlade](https://www.cnblogs.com/pigpdong/p/10932415.html)
+1. [混沌工程原则](https://www.jianshu.com/p/5d13540b53c3)
+1. [principles of chaos engineering](http://principlesofchaos.org/)
+1. [饿了么异地多活技术实现1](https://zhuanlan.zhihu.com/p/32009822)
+1. [饿了么异地多活技术实现2](https://zhuanlan.zhihu.com/p/32587960)
+1. [饿了么异地多活技术实现3](https://zhuanlan.zhihu.com/p/33430869)
+1. [饿了么异地多活技术实现4](https://zhuanlan.zhihu.com/p/34958596)
+1. [ref](https://blog.csdn.net/hxpjava1/article/details/86592360)
+1. [ref](https://www.sohu.com/a/158859741_444159)
+1. [异地多活 IDC 机房架构](https://www.upyun.com/opentalk/377.html)
+1. [异地多活场景下的数据同步之道](http://www.tianshouzhi.com/api/tutorials/canal/404)
+