Page History

...

그 어떠한 결정과정은 , 메일함 어딘가에 있습니다. 메신져 어딘가에 있습니다. 친절한 담당자가 

잘 대응을 해주었으니까요.  장애처리와  그렇게 매직 코드는 쌓여만 갑니다.

장애처리와 관련해서는 해결을위한 처리도 원인 파악을 통해 이루어졌지만

지식및 운영에 관련하여 그어떠한 노하우도 쌓이지않고 추적이 되지 않으니 또 생깁니다.

연말에 과거1년을 돌아보면, 이상하게 비슷한 날짜에 같은 장애처리를 합니다. SSL인증서 만료처럼

우리는 1년이 지나면 잊어버리게 되어있습니다. 1년전에 발생한 장애이슈에대해

한번한 실수는 보통 한사람이 다시 잘안합니다. 시간이지나면 하거나 과거에했던 누군가의 실수를 팀내 다른사람이 되풀이할뿐이죠

하지만 우리들만의 방식으로 잘 운영이되고있습니다. 운영팀을 도입했지만, 그들은 서버를 켜고끌뿐입니다.

개발과 운영이 분리되지 않습니다. 왜? 개발자가 직접 배포하고 운영도 해야 하니까요

우리는  남들이 컨트롤 못하게 곳곳에  수동조작 버튼을 곳곳에 심어놓았습니다. 그리고 그것은 문서화도 안되어있습니다.

새로 영입된 아키텍트는 한참 분석하더니 결론을 내렸습니다. 이것은 블랙 박스다라고 

언젠가 팀장이 아키텍트역활을 한다라고 들은적이 없습니다. 팀장은 결코 자신의 팀코드를 블랙박스다란 결론을 내릴수없습니다.

 이것을 지켜보는 상위 관리팀에서 극단의 지침을 내립니다.

...

티켓:특정한 것을 할 수 있는 자격. (네이버사전)

처음에는 , 뭔가 답답했습니다. 

내가 하는일이 무엇이지? 어떻게 누구에게 할당을 해야하지? 내용은 어떻게 작성해야하지?

타팀에 업무요청을 하려면 적어도 티켓화를 통한 구체화를 해야했습니다.

그리고 그 과정에 하는일의 제목을 무엇으로 달지?  할당은 누구에게 하지? 그냥 담당팀 아무개한테 해달라고 하면 해줬는데~~

그러면서 잘못된 세가지를 알게되었습니다.

• 상대팀의 리소스를 , 내가 함부로 사용할수 없다란것. 
• 또한 그 리소스에 대한 역활이 역활및 사용권한에대해  애시당초 정의한적 없었다란것
• 미리 계획할수 있었에도 불구하고 , 우리팀에서는 이거안되면 안되 긴급으로 문의를 한것계획하고 요청했을 기회를 무시하고 , 나중에 언제든 요청하면 바로 해주겠지하고 미룬것

기존에는 이러한게  미덕이였습니다.

• 퇴근시간까지 긴급하게 퇴근시간 갑자기 생긴일에 응대를 해주면 착한 개발자 ,개발자 
• 문의받은 그내용이 무엇인지 어렵풋이알지만 신속하게 잘못된 정보로 응대를 해줘도 착한 개발자였습니다.개발자

 어쨋건 우리가하는일을 트래킹 시스템을 도입하고 ,아주 세세한 일까지

...

 각 개발팀이 모여 어떻게 누가? 어떻게 개발해야할지 분석에 들어갑니다.  PM은  

PM은 이때 냄새를 맡고 , 개발관련 스케쥴을 컨트롤 하려고 합니다. 그리고 으 프로젝이 런칭될때까지 책임을 집니다.

"PKIV-001-다중기기 사용자를 대비한 멀티 로그인  대장정(EPIC)"  일단  우선 가장 거대한 티켓을 만들고 봅니다.  

(여기서 PKIV는 프로덕트기준 그들만이 사용하는 약속된 개발관련 티켓명이며 접두어이며 자동으로 붙습니다.)

아키텍트의  아키텍트의 참관하에 BA가 설명을하고 어떤 개발팀이 필요한지 물어봅니다.  개발팀의  

개발팀의 거짓말을 방지하기위해 감독역활로 아키텍트는 그냥 참관합니다. 가끔 이건 안되요 하면 아키텍트가 열심히 리서치해서

해법을 찾아주기도 합니다. 아주 자끔입니다.

QA는 QA범위 산정을 위해 미리 참관을하지만, 기존 새롭게 작동되는 방식에대해 더많은 설명을 하게되며BI를 가르쳐줍니다. 이것은 문제가 될것 같은데요 라구~~ 의문을 제기합니다.  

서버팀도 한마디 합니다. "이거 부하 증가가 예상되어 로그인서버 2대더 필요합니다." 하지만  뒤늦게 후회합니다.

...

알고싶지는 않지만, 서버두대 추가로 해야되는 고급 일들이 많아 보입니다. 그리고 데브옵스는 임무를 마치고 자기일 하러 갑니다. 

결국 DB / 서버 / 클라이언트/모바일팀  4팀에서 개발을 하기로 결정하고 기획서의 숨겨지고 함축된 의미에 대해

기획문서를 두리뭉실하게 재해석을 하고 파이팅을 외치며 회의는 끝나게 됩니다. 금요일은  빨리 퇴근 해야하기떄문에 이야기가 길어지면

안되기때문입니다.

설계

 아키텍트는 이떄부터 개발팀과함께 다이어그램을그리기 시작하며

...

똑똑한 클라이언트 개발자는 아키텍트를 설득시켜 다시 넘기기도합니다. 그리고 그것은 다시 DB로 넘어가기도합니다.

아키텍트는 아름다운 중재를 합니다. 반반씩 해라~~~  DB반 서버반....  이 단계가 길어집니다. PM이 개입합니다.

뭣이 중한디? 아무나 빨리하고 일정을 맞추시오. 비지니스로직이 DB로 가면 공수가생겨 업데이트가 연기가 됩니다

PM이 BA및 아키텍트의 조건부 승인을 받아냅니다. 런칭 날짜가 더 중요하니 이 로직은 그냥 서버에 있게하자~~ 

어느정도 아키텍쳐가 그려지는듯 하더니   이러는 동안 PRD(프로덕요구사항)에 수정이 일어나고,

...

멀티 로그인 허용이지만 모바일은  허용하고,PC는 비허용

다시 분석단계를 돌아 설계단계로 와서 이때까지한 설계가 수포로 돌아가거나, 수정이 필요합니다.  아키텍/개발자/기획 의 논쟁이 끝나지 않습니다.

이런문제는 관련 충돌 담당자 모두를 수용을 시켜야 해결이되며, 일을 시작할수 있습니다.

이때 영웅이 항상 해결자가 등장하여, 어떠한 중립적인 아키텍쳐를 제시하여 그 문제를 해결을 합니다.  

...

숫자로 기억됩니다.  7782번 티켓이라고  ..... 개발시간을 다 까먹었지만 릴리즈 날자는 변경없이 다음 단계로 돌입하게 됩니다돌입하게되며

QA는 조용하게 이때까지 준비한 테스트 케이스를 폐기하고, 최종 결론본에 맞춰 처음부터 다시작성합니다.

개발

그이전에 수많은 분석및 설계 티켓이 먼저 생성되었지만 생략하였습니다. 그것은 티켓번호 7782입니다.

PKIV-001 대장정대서사시(EPIC) 에대한 서브 티켓으로  스토리가 생성됩니다생성되었습니다. 

• PKIV02-DB팀의 다중 로그인 추가에 대한 이야기(STORY)
• PKIV03-서버팀의 다중 로그인 추가에 대한 이야기(STORY) 
• PKIV04-클라이트팀의 다중 로그인 추가에 대한 이야기(STORY)
• PKIV05-다중로그인 테스트에대한 아름다운 QA의 이야기(STORY)

...

진행사항을 PM이 개입하기 시작합니다. PM은 스토리 과정에 관심이 없고 스토리가 모두 완료되는것에만 관심이 있습니다.

실질적인 하위 일(TASK)이 빨리끝나 이야기를 끝내어야 하기때문에 모두 끝나야 각팀의 이야기가 끝나기 때문에 당근과 채찍을 준비합니다.개발팀은 당근과 채찍을 구분을 하지 못합니다. 그냥 일이 생겨 일을 하기 시작하며  

소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 쓸모없습니다.

...

(QA를 또해야한다는 뜻)

우리끼리 약속한 릴리즈가 프리징단계에서는 문제가 없을것이라고 프리징단이 문제없을것이다라고 희망을 합니다.

INT-QA

INT환경은 소스통합 테스트를 위한 개발환경이 아닙니다. 소스통합에 따른 문제는 DEV단계 Release를 Release 프리징을 통해 이미 완료 되었으며

희망사항이 이어진다고 하면, 여기서 넘어온 릴리즈 환경이 리얼서비스환경에 반영이되어도 문제가 없어야합니다. 

이상은 그렇지 않습니다. 그래서 DEV에 했던 단편적인 테스트를 모두 집합시켜 풀테스트를 진행합니다. 

가끔 이런의문을 가집니다. 우리가 통합한 소스중에  INT에서 50%를 빼겠다고  왜 이러것이 이런 문제제기를 합니다.  INT에서 10%를 빼겠다고, 왜 이런것이 깔끔하게 안되냐고?

답은 간단합니다  INT를 포기하고 DEV단계로 다시 가십시오라고~~가야하는 이슈입니다. 소스머지가 완벽한다고 해도 안될일입니다.

애시당초  기능활성 미지수인것은 실시간 옵션화로 미리 계획되어야 되는일이며 실제로 수많은 예상기능들이

그렇게하여 소스와 머지된상태로 비활성화되어 올라갔습니다.

INT환경은  또한 실제 서비스환경과 비슷한 테스트 환경으로,  DB 역시 서비스수준으로 노이즈가 없어야합니다.

...

코드프리징이 일어난 Release라 할지라도 작은범위의 변경정도는 할수가 있습니다. 적어도 변경범위에따른 QA 변화량을

측정후 변경이 일어나야합니다. 이 경우도 심각도에따라 크지 않는이상, 그냥 올리는 경우도 발생합니다. 

A를 고치니...더 중요한 B문제를 놓치는 케이스가 분명 있기때문입니다.  

이것은 이미 보고된 문제임으로 프로덕트 조건 승인이 이루어져야 가능한 일입니다.

자 모든 QA활동을 마쳤습니다.

SignOff는 Release → Master로 통합될수 있다란 의미이자  실반영을 해도 된다란 약속이며 실제로 머지가 됩니다.

...