유지보수 Flashcards
sw 유지보수
[리드] SW 생명 연장
[정의] SW가 인수, 설치된 후 폐기될 때까지 결함제거, 성능향상, 변화된 환경에 소프트웨어의 수명을 연장시키는 일련의 행위
[필요성] 지속적 변경(추가 결함 제거, 요구 변화 대응), 성능 저하(품질 저하 방지, 복잡도 개선), 환경 변화(운영 환경 및 정책 변화 대응)
* ISO/IEC 14764 표준 기준. IEEE 1219 에서는 예방대신 긴급(Emergency) 유지보수 유형을 정의
[유형] (수완예적)
- 수정 유지보수 : 오류 결함 수정 (프로그램 오류 / Application 코드 수정, DB쿼리수정)
- 적용 유지보수 : 변화/갱신의 적용 (프로그램 환경 변화/시스템 변경, 장비교체/ 디비이관, 설정변경, 재설치)
- 완전 유지보수 : 불완전 부분 표준화 적용 (프로그램 기능보완,수행 능력 향상/ 기술표준화,통합IF)
- 예방 유지보수 : 장기적 유지보수 (예측 오류 선점처리/정기점검, 3R/log분석, 디비백업)
* 지속되는 SW 변경의 제어, 추적을 위해 형상관리 사용
리만의 법칙
[정의] 변경에 따른 복잡성, 프로그램의 고유한 변경 추세, SW조직 생산성의 일관성, 소프트웨어 각 버전의 변화에 대한 일관성을 제시한 SW 변화의 원리
* 소프트웨어 변화의 특성을 이해하고 유지보수, 변경관리, 형상관리, 품질통제의 중요 모델로 반영
[SW 변화 원리 분류(Catetory)]
- S-Type : 명세 (정해진 명세에 따라 정확히 동작하는 S/W) - 계산기 프로그램
- P-Type : 절차 (절차나 실행 입력 값에 따라 다르게 수행되는 S/W) - 체스게임
- E-Type : 환경 (실 세계의 환경적 상황과 밀접하게 연관되어 동작하는S/W) - 열감지 센서, Tax시스템
* 리만은 위의 분류 중 E-Type에 대한 변화 원리를 제시
[SW 변화 원리] 원리/적용방안 (변복진안친성품피)
1. 지속적인 변경의 원리 : 요구사항에 의해 계속 변경 (요구관리프로세스, 변경관리 프로세스)
2. 복잡도 증가의 법칙 : 변경 -> 복잡도 증가 (3R-역공학,재사용,재공학)
3. 프로그램 진화의 법칙 : 변경의 고유한 패턴/추세
4. 안정성 유지의 법칙 : 조직의 생산성이 조직 변화에 민감하지 않음 (변경통제위원회(CAB),형상통제위원회(CCB))
5. 친근성 유지의 법칙 : SW 각 버전의 변화 일정, 규칙적 수행 결과 (형상관리시스템, Git,SVN)
6. 지속적 성장의 법칙 : 사용자 만족을 위해 지속적 성장 (CI/CD, DevOps,SRE)
7. 품질 저하의 법칙 : 변화가 지속되면서 기능은 증가하지만 품질은 저하 (리펙토링, 회귀테스트)
8. 피드백 시스템의 법칙 : 피드백 형식으로 변화가 지속 (Baseline, CMDB)
3R
[정의] Repository 기반 역공학, 재공학, 재사용 통한 SW 생산성 극대화 기법
[필요성] 운영 시스템 노후화, 신규 시스템과의 호환성, 유지보수/개발비용 증가
[기대효과] 운영 신뢰성 향상, 유지보수 비용 절감, SW변경 요구의 신속대응
[유형]
1. 역공학(소스(코드, 데이터)→ 설계) : 자동화 도구 활용(디컴파일러), 논리 역공학/자료 역공학
2. 재공학(역공학 이후 추상개념 현실화) : Bad Smell, 리팩토링
3. 재사용(재공학 이후 실제사용) : 디자인 패턴, OOD, CBD
[고려사항]
1) 역공학 : 기술, 저작권 유출 문제 → 난독화 수행[제어/자료구조/바이너리/소스]
2) 재공학 : Rollback, 회귀테스트 수행
3) 재사용 : 응집도 향상(캡슐화), 결합도 감소(정보은닉)
역공학
[정의] 대상 시스템 분석, 시스템 컴포넌트의 관계 파악을 통해 같은 수준의 다른 표현이나 더 높은 추상 수준의 표현으로 만드는 작업
[필요성] 기존 SW 분석 (다이어그램), 유지보수성 향상, 문제 감지(정형적 분석), 리엔지니어링(SW개선)
[프로세스]추분문원
1. Code 추출 : 자동화 도구 사용, Dirty Code 추출 (Decompiler)
2. Code 분석/수정 : 정적/동적 분석 및 Clean Code화, Wireshark(Packet분석, 클래스, 속성, 관계)
3. 문서화 : 분석된 코드 기반 명세서 작성, 설계 최적화 (클래스/시퀀스 다이어그램)
4. 원시 코드 생성
* Target System (디컴파일) → 원시/실행 코드 → (분석/추출) → 시스템 정보 저장 → 문서화
[기법 유형]
- 추상화 수준 측면 : 재문서화(같은 추상 수준을 가진 문서 생성, 원시코드->자료,제어흐름도), 설계 복구 (의미 있는 추상성 높은 표현 추출, DB->ERD)
- 역공학 대상 측면 : 논리 역공학(원시코드로부터 정보 추축, SW 설계 정보 생성), 자료 역공학 (데이터, 파일 시스템으로부터 정보 추출, DB 구조 정보 생성)
- 시스템 분석 측면 : 디컴파일, 디셈블러
재공학
[정의] 아키텍처 개선, 복잡도 경감 등 SW 시스템 구조 개선을 통한 유지보수 효율성 및 품질 향상 목적, 재구조화 기법
[필요성] 유지보수성 향상(아키텍처 개선, 변경 적응성 개선) , 품질/보안성 향상(복잡도 경감, 성능/효율성/자원유용성 개선), 리스크 감소, 비용 절감, 생산성 향상
* 시스템 구조에 적합한 설계 패턴 적용, 시스템 및 컴포넌트 재구조화 수행
[수행절차]위전구평
- 개선 위치 파악 -> 개선 전략 선택 -> 개선 구현 -> 목적대비 평가
[수행전략]
- 개선 위치 파악 : 소프트웨어 분석, 개선 필요 항목 도출 (LOC, 함수 복잡도 측정, 정적 분석)
- 개선 전략 선택 : 변경 효과 및 구현 비용 분석, 개선 전략 선정 (데이터/제어 흐름 변경 영향 분석)
- 제안된 개선 구현 : 코드/데이터 재구성 (Clean Code, 컴포넌트 재구성, 리펙토링)
- 목적 대비 평가 : 프로세스 반복,개선 수행 (Matric 측정 결과 평가, 컴포넌트 성능 평가)
* 효과적인 재공학을 위해서는 기존 시스템의 가시성 확보 및 지속적인 개선이 중요
[고려사항]
- 역공학 선행 : 재문서화, 설계 복구 통한 시스템 가시성 확보
- 리엔지니어링 프로세스 최적화 : CMM, SPICE(ISO/IEC 15504) 기반 평가, 개선 체계화
* Lehman 의 소프트웨어 진화법칙 고려, ISO/IEC 12207 기반의 체계적 SDLC 관리 필요
재사용
[정의] 소프트웨어 개발 관련 지식(기능, 모듈, 구성 등)을 표준화하여 개발 생산성 높이기 위해 반복적 사용에 적합하도록 구성하는 기법
[필요성] TCO 절감, 품질 확보, SW위기 극복
[원칙] 범용성, 모듈성, 독립성, 일반성, 신뢰성
[SDLC 단계별 재사용 요소]
- 요구분석(환경정보,외부지식), 설계(기본,상세,데이터 설계), 구현(모듈,프로그램), 테스트(Case), 유지보수(사용자 메뉴얼, 프로토타입, 타당성 조사 결과/자료)
[기법]
- 활용 기법 : Copy, Pre-processing, Library, Package, Object, Generics, 객체지향
- 구현 기법 : 컴포넌트, 디자인 패턴, 모듈화, 분류(Code Dictionary), 객체지향 방법론, CBD
* 성공적인 재사용을 위해서는 재사용 자산의 개발과 함께 체계적인 지원 및 관리가 중요
리팩토링
[리드] Code Smell 제거
[정의] 기능 변경없이 로직개선 통한 SW 안정성/신뢰성/재사용성 향상 기법
[필요성] 유지보수성 향상, 유연한 시스템, 생산성 향상, 품질 향상
[주요기법]
- 메소드 정리 및 단순화 : 긴 메소드 분할, 중복 메소드 통합 , 메소드 명 변경
- 클래스 확장성 개선 : 객제간 기능 이동, 클래스 일반화, 인터페이스로 공통기능 분리
- 코드 최적화 : 조건 논리 단순화, 미사용 변수 삭제, 반복 실행 코드 분리
[고려사항] 리팩토링 수행 전 유닛테스트 수행. Side Effect 검증 필요, Rollback 정책 수립 필요, 완성된 코드, 버그 적은 코드 사용 시 효과
* 정적 분석, 프로세스 자동화 연계를 통해 MSA 환경에 최적화된 SW 품질 보장
모듈화
[정의] SW 성능을 향상과 디버깅, 테스트 및 수정을 용이하게 할 수 있도록 추상화하여 설계하는 기법
[특징]
1. 모듈성 : 시스템분해 및 추상화 성능향상
2. 응집도 : 모듈의 독립성
3. 결합도 : 모듈간 연관성
[원리]
1. 모듈과 비용 관계 : 모듈 수 증가시 인터페이스 비용 증가
2. 정보 은폐 : 어렵거나 변경 가능성이 있는 모듈 타 모듈로부터 은폐
3. 자료 추상화 : 각 모듈 자료구조 액세스/수정 함수 내 자료구조 표현내역 은폐
4. 모듈의 독립성 : 낮은 결합도/높은 응집도
응집도
[리드] 모듈의 독립성
[정의] 모듈안의 요소들이 서로 관련 있는 정도로 한 모듈내 구성요소의 기능적 관련성 평가 기준
[종류] (우논시절통순기) 1(낮음) → 7(높음), 응집도는 높을수록 좋음.
1. 우연적 : 관련 없는 작업 한 모듈에서 모음
2. 논리적 : 유사 성격 작업 모음
3. 시간적 : 동 시간대 처리해야 할 작업 모음
4. 절차적 : 모듈 간 진행 요소 순서대로 진행
5. 통신적 : 동일 입출력 자료 이용 서로 다른 기능 수행
6. 순차적 : 작업의 결과가 다른 모듈의 입력자료로 사용
7. 기능적 : 하나의 기능만 수행하는 모듈
결합도
[리드] 모듈간 연관성
[정의] 모듈 내부가 아닌 외부의 모듈과의 연관도 또는 모듈간의 상호 의존성을 나타내는 정도
[종류] (내공외제스자) 1(높음) → 6(낮음), 결합도는 낮을수록 좋음.
1. 내용 : 한 모듈이 다른 모듈의 내부자료나 제어정보를 사용
2. 공통 : 많은 모듈들이 전역변수를 참조할 때 발생
3. 외부 : 모듈들이 소프트웨어의 외부환경과 연관 되는 경우
4. 제어 : 제어용 신호를 주고 받음
5. 스탬프 : 모듈 사이에 자료구조 교환
6. 자료 : 모듈들이 간단히 변수를 파라미터로 교환
Fan-in/Fan-out
[리드] 재사용을 위한 기능 단위 분해, 소프트웨어 모듈 개념
[개념] 소프트웨워의 기능 단위 분해 및 추상화 수행, 재사용성 향상 및 공유 가능 수준으로 설계된 소프트웨어 단위
* 소프트웨어의 객관적, 정량적 품질 측정을 위해 fan-in, fan-out Metric 활용
[Fan-In] 모듈을 계층적으로 분석하거나 시스템 복잡도를 측정하기 위해 어떤 모듈을 호출하는 모듈의 수를 분석하는 기법
- 자신을 기준으로 모듈에 들어오면 Fan-in으로 카운팅
<고려사항>
- fan-in이 높은 경우 재사용 설계가 좋음
- 단일 장애점(SPOF) 발생 가능
- 관리 및 테스트 비용 증가
[Fan-Out] 모듈을 계층적으로 분석하거나 시스템 복잡도를 측정하기 위해 어떤 모듈에 의해 호출되는 모듈의 수를 분석하는 기법
- 자신을 기준으로 모듈에 나가면 Fan-out으로 카운팅
<고려사항>
- 높을경우 불필요한 모듈 호출 증가 위험
- 단순한 기능 여부 검토 필요
*이외에도 요구, 설계, 코드, 시스템 Metric 을 활용, SW 품질 측정 및 개선 수행
</고려사항></고려사항>
SW 모듈 품질 측정 Metric
[SW 모듈 품질 측정 Metric]
- 요구 Metric : 요구의 비모호성, 완전성, 정확성, 일관성
- 설계 Metric : 응집력, 결합력, 모듈성, 설계 복잡도(*fan-in, fan-out 도 해당)
- 코드 Metric : LOC(Lines of Code), 싸이클로매틱 복잡도(CC)
- 시스템 Metric : 신뢰도(MTBF + MTTF + MTTR), 가용성(MTBF/(MTBF+MTTR))
* ISO/IEC 25000(품질평가 통합모델), ISO 9001(품질경영시스템 인증) 등 표준체계를 활용한 객관적 평가 및 지속적 프로세스 개선 필요
SW 메트릭
[정의] SW 품질 특성 수치화, 정량화 통한 품질 목표 명확화, 개발 체계화, 유지보수성 향상 목적 SW 품질 측정, 평가 지표
[측정유형]
- Measurement : 어떤 현상, 특성, 결과를 숫자로 표현하는 활동
- Measure : 측정 방법의 표준 (FP, 본 수, 결함 수, 투입 공수 )
- Metrics : 프로세스, 컴포넌트, 시스템 속성이 숫자로 계량된 측정 항목
[SW 메트릭 유형]
1. Product Metric : 제품 평가 및 추적과 관련한 측정 (크기(LOC, FPC), 복잡도(McCabe 회전복잡도,
2. Process Metric : 프로세스 성과 및 분석 (프로세스 준수율, 품질 실패 비용율, 결함제거율, 테스트 효과성)
3. Project Metric : 프로젝트 진행 관리 (공정진도 준수율, 예산 준수율, 투입공수 준수율)
[프로세스] 식자계분검
- SW 품질 요구사항 설정 → SW Metric 식별( 메트릭 집합/명세서) → 자료수집 → SW Metric 계산 → SW Metric 결과 분석 → SW Metric 검증
시각화
[정의] 소스코드와 개발 프로세스 관리 위해 문서화, 시각화 통한 비가시성 극복, SW개발 품질향상 기법
[효과] 정량화, 투명성, 관리 용이성
[지표]요형품결
1. 요구사항 : 요구사항 추적성 / 달성율 / 커버리지
2. 형상관리 : 형상항목 / 등록율 / 변경율
3. 품질검증 : 동적테스트(기능검증, 비기능검증, 정형검증, 사용자검증, 구조커버리지) 정적테스트(코딩 표준준수율, 메트릭 만족율, 정적분석이행율)
4. 결함수준 : 결함조치율 / 결함밀도
[도구] SDLC 구현 방안
- 요구관리(Redmine, Jira), 개발(Eclipse, Spring IDE), 빌드(Ant,Maven), 정적분석(CppCheck, PMD, FindBugs), 동적분석(WB-JUnit, Emma, BB-Impasse), 형상관리(Subversion, Git, SVN, CVS), CI(Jenkins)/배포관리(Hudson, Chef, Maven)
난독화
[정의] 역공학을 통한 보안취약점 공격에 대한 방지 기술로 코드를 복잡하게 만들어 원시 코드를 알아보기 어렵게하는 기술
[필요성] 불법 복제 방지, 해킹 방지, 소프트웨어 경량화
[종류] 소스코드 난독화, 바이너리 난독화
[절차] 1.분석 2.기법선택 3.코드 난독화 수행 4.기능 검증
[코드 난독화 기술] (구데집제예)
- 구획(Layout) 난독화 : 형식 변화, 주석제거, 식별자 손상
- 데이터 난독화 : 변수 자르기, 정적자료의 절차적 자료화
- 집단 난독화 : 자료 순서 변경, 클래스 분할
- 제어 난독화 : 프로시저 인라인/아웃라인화, 프로그램 실행 순서 변경, 데드코드 삽입
- 예방 난독화 : 알려진 역난독화 봉쇄, 고유 난독화 방법
형상관리
[정의] (가추무) SDLC 상 코드 및 산출물의 체계적 관리 위해 가시성, 추적성, 무결성 확보하는 품질보증 기법
[기능] 형상 Freezing, Repository, CCB, 변경관리, Baseline 관리
절차 수행내역 / 획득효과
1. 형상 식별 : 대상구분, 관리목록 번호 부여(REQ 1.1) → SW 가시성 / 추적성 확보
2. 형상 통제 : QA, QC(변경 요구 검토, 통제) → 산출물 일관성. Gold Plating, Scope Creep 방지
3. 형상 감사 : Baseline, CCB 승인 → Baseline 무결성 평가, 기술/표준/프로세스 공식 검토
4. 형상 기록 : Repository, 버전관리 → 버전/변경관리, GIT/SVN/CVS
[구성요소] 형상/관리기법(식/통/감사/기록), 형상관리 리파지토리(저장/변경), 형상관리위원회(변경승인/확인)
[산출물] 형상관리 계획서, 형상항목 관리대장, 형상감사 보고서
형상통제
[정의] 라이프 사이클 상 식별된 형상항목에 대하여 변경에 대한 내역 및 영향분석, 평가, 승인 및 배포 등을 수행
[절차] 변경요청(요청서 작성/제출) → 변경심사(CCB검토/변경승인기각결정) → 변경실시 (변경대상 식별/변경수행) → 변경확인(변경완료/기준선관리) 요심실확
[변경통제위원회(CCB)의 주요 절차 와 역할]
<주요절차>
- 변경검토(변경제안 제출/변경반영 검토) → 변경영향 평가(영향대상 확인, 변경영향 평가) → 변경효과 점검(효과성 검증, 쟁점이슈 처리) → 변경통제 승인 및 후속조치(변경기준선 재수립, 문서화및 후속조치)
<역할>
- 베이스 라인 검토 및 승인 : 형상항목 결정, 베이스라인 수립여부 결정, 승인된 변경에 대한 책임 및 보증
- 변경 영향평가 및 승인 : 우선순위 제약사항 고려, 작업기간/범위/기간등 결정, 이해관계자간 대립 중재
</역할></주요절차>
ITSM
[리드] 비즈니스 전략과 IT서비스 전략연계
[정의] Business Value제고, IT비용 효율화, 변화에 대한 능동적 대처를 위한 IT 서비스 전략 프레임워크
[목표] IT서비스 만족도, 프로세스 혁신, R&R 명확화, IT부서 조직체계 혁신
[구성]
1. 서비스 지원(Service Support) 영역(서인문 변일형)
- 서비스데스크 : 인시던트 해결 운영 단일접점(SR(Service Request, CR), Call Center)
- 인시던트 관리 : 장애처리, CMDB 활용
- 문제관리 : 근본적 원인 해결, 재발 방지
- 변경관리[요평수기-요청/평가/수행/기록] : CCB, CAB, 회귀테스트
- 릴리즈관리 : Regression Strategy(롤백전략), Blue/Green 배포 전략
- 형상관리 : 버전관리, Baseline관리, SLA 관리
2. 서비스 제공(Service Delivery) 영역(용가연수재)
- 용량관리 : Biz 요구사항 부합하는 IT자원 성능,용량 관리
- 가용성관리 : Biz 목표달성, 가용수준 유지,지원 조직
- 연속성관리 : 사건 발생시 합의된 시간 및 범위내 복구 및 연속성
- 서비스수준관리 : 모니터링, 리포팅, 개선활동 반복 수행, 품질유지
- 재무관리 : IT자산, 비용 효율적 사용
변경관리
[정의] CAB/CCB 통한 변경영향 최소화, 표준화된 방법, 절차 사용 보장, 관리기법
[프로세스] (요분승실검종)
1. 변경요청(RFC 등록) - 개발부서/사용부서에 변경사항 발생시 변경요청서(RFC) 변경요청
2. 평가(영향도 분석) - 변경적합성 판단, 회송/변경 모델 결정
3. 변경승인(형상통제, CAB/CCB) - 단순/긴급/일반변경, 구성관리 갱신
4. 변경수행(실행)(4. 설계 5. 구현 6. 릴리즈)
7. 변경후 검토(요청자 충족) - CMDB 적용, 변경관리대장
8. 변경종료
무중단 배포 기법
[정의] 영속성과 안정성 보장 위해 운영환경에 배포시 서비스가 중단되지 않도록 소스 deploy 하는 기법
[중단배포 문제점] 다운타임 발생, 가용성 침해, 운영 안전성 저해
[배포방식] (블롱카)
1. 블루그린 배포 : 운영과 동일환경에 새 버전 배포 후 스위칭, 비용 증가
2. 카나리아(Canary) 배포 : 위험 검증, 일부 사용자 테스트 후 전체 사용자 오픈, 버전 관리 필요
3. 롤링 배포 : 신버전 서버를 만들어 가면서 순차적으로 이전하는 방식(9:1, 8:2, …. 0:10), 구/신버전 호환성
ISO 20000
[정의] ITIL 기반 IT 서비스 관리체계 성숙도/수준(아웃소싱 운영체계) 평가 국제인증 표준
[구성]
1. Part1 : 서비스 관리 인증규격(Specification), 요구사항 정의
2. Part2 : 서비스 관리 실행지침(Code of Practice), 요구사항 달성 가이드
[절차]
- 사전질의 > 신청 및 심사팀 배정 > 문서심사 > 예비심사 > 본심사 > 인증 > 상호심사
[진단기준] (중경시개)
1. 중부적합 : 인증요건 충족 문서 및 기록이 없어 인증규격 위배
2. 경부적합 : 문서 미흡, 보완필요, 한 프로세스에 Miner NC가 4건 이상시 Major NC 됨
3. 시정요구 : 조직의 관심 필요
4. 개선권고 : 인증 부합 및 개선 될 서비스 향상 기대
[서비스 관리체계]
1. 서비스 관리시스템(SMS) : 관리책임, 문서화, 인식 및 교육
2. 신규/변경서비스 설계 및 전이 : 서비스기획, 실행, 모니터링, 지속개선
3. 서비스 Delivery 프로세스 : 용량관리, 가용성관리, 서비스연속성관리, SLA, 서비스보고, 보안관리
4. Control Process : 구성관리, 변경관리, 배포관리
5. Resolution Process : 인시던트 및 서비스 요청관리, 문제관리
6. Relationship Process 비즈니스 관계관리, 공급자 관리
CMDB
[정의] IT 서비스, CI(Configuration Item) 정보 실시간 통합 관리, IT 프로세스 가시성, 추척성, 무결성 향상 데이터베이스
[관리항목] (서인문변)
- 서비스(SR접수/처리로그), 인시던트(장애접수/처리), 문제(원인/처리결과), 변경관리(버전/변경이력관리
[관리기준] SLA, ITSM 프로세스
[구축절차]
1.Legacy(자산) 이관 2.고도화(서비스 Delivery 시스템, ITSM 체계 모델) 3. 서비스 Support 연계 4. 통합 IT 서비스
성과관리
[정의] 정보시스템 운영 타당성을 판단하기 위해 성과를 측정하고 평가하여 업무 및 비용 측면의 성과를 높이기 위한 제반 활동
[적용근거] 전자정부법 제45조 3,4항
[성과측정 기준]
- 비용 측면 : 운영의 적정성, 유지의 용이성, 비용 효율성
- 업무 측면 : 기능 활용도, 사용 편의성, 업무 성과 달성도
[성과 측정 방법]
- 관점별 성과측정(지표) → 유지관리 유형(유지,고도화,재개발,폐기) → 폐기 검토 및 유형재분류 → 자원 효율성 측정 → 구축방안 정의 → 투자 타당성 분석 → 최종 의사결정
SRE
[리드] DevOps 구체적 접근법
[정의] Devops 실제 적용시 운영,개발 Silo 현상 해결 위한 SLI, SLO기반 시스템의 지속적, 적절한 수준의 안전성,신뢰성 확보위한 고도공학기법
[원칙] 1) 가용성에 대한 명확한 정의 2) 가용성 목표 정의 3) 장애발생에 대한 계획
[필요성] 1) 적절한안정성 달성(시스템/서비스 장애 최소화) 2) 지속가능한 운영방식수립(현업직원 업무 집중 지원)
* 지표 설정과 시스템 장애 최소화 운영 통한 적정 수준 안전성 달성
[SRE 핵심요소] 구현방안/주요기법 (지용변장문)
- 지표관리&모니터링 : 정량적 모니터링 지표 정의, 안정성 목표 정의 (SLI, SLO)
- 용량계획 : 충분한 H/W 리소스 파악,자원 활용 효율성 측면 안정성 최대화 (수요기반 예측, 성능 튜닝)
- 변경관리 : SW 점진적 배포, 업데이트, 변경관리, 장애 시 빠른 파악/롤백 (카나리배포, 롤링업데이트)
- 장애대응 : 장애 시 빠른복구로 장애시간 최소화, 장애 복구 모의훈련 (MTTF,MTTR, Playbook)
- 문화 : 데이터 기반 의사결정, 비난 보다 장애 분석 (ErrorBudget, 책임 공유문화)
* SRE 는 DevOps 구체적 접근법으로 성공적인 조직 내 정착을 위한 수행방법을 제시
[SRE 수행 방법] (사실점자측)
1. Silo 조직의 통합 : 오너십 공유
2. 실패에 대한 수용 : Postmortem(사후검토) 회고, Error Budget 관리
3. 점진적 구현과 개선 : 카나리 배포, 롤링 업데이트
4. 자동화 시스템 사용 : Toil 관리
5. 모든 것에 대한 측정 : 시스템 지표
