@realmankwon입니다.

추석이 지나자 희한하게도 봇들이 안정적으로 돌아가고 있습니다.
제가 소스를 수정하여 적용한 후에 재부팅한 것을 제외하고는 뻗은 적이 없는 것 같습니다.
지난주에도 스팀 api 를 호출하면서 대기된 상태의 에러 외에는 문제가 없었던 걸로 봐서는 스팀 api 가 안정적으로 동작을 하고 있는 것 같습니다.
안정화 작업을 하라고 평온한 때가 온 듯 합니다.

# 1 . 블럭 저장 봇 모니터링 
- 가장 중요한 스팀 블럭 정보를 저장하는 봇을 모니터링하는 봇을 개발 중에 있습니다. 현재까지 읽은 가장 마지막 블럭 번호를 읽고 3분 뒤에 다시 마지막 블럭 번호를 읽은 후에 비교하여 동일하면 블럭 저장 봇을 재부팅 시키도록 할 예정입니다.
- 개발은 완료하였는데 재부팅시에 제 예상과 다르게 동작을 하였습니다. 노드를 forever 로 실행시켰는데 forever 프로세스 는 보이지 않고 실행시킨 블럭 저장 봇 프로세스만 보였습니다. 이 부분만 해결하면 스팀 api 문제로 홀딩이 걸리는 문제는 해결이 될 듯 합니다.

# 2 . 리팩토링
> 리팩터링(refactoring)은 소프트웨어 공학에서 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다. 사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다. - 위키백과 -

- 기존 소스에 대해서 일부 리팩토링을 실행하였습니다. 위의 설명대로 결과값에는 변화가 없기 때문에 아무런 차이를 느끼지 못하실 겁니다. 하지만 개발자의 입장에서는 추후 변경이 더 용이해지고 한편으로는 성능이 향상되는 효과도 있기에 안정화 작업때는 리팩토링을 병행할 때가 많이 있습니다.
- 특히나 협업을 해야 하는 상황이나 시스템 유지보수를 할때에는 반드시 간결하고 쉬운 코드로 작성을 해야합니다. 그래야만 누구나 그 소스를 쉽게 문제없이 수정이 가능하기 때문입니다. 그래서 리팩토링을 통해서 더 가독성이 좋은 소스로 변경을 해 나가는 것이 추후에 장애에 대응하기가 쉽습니다.

# 3 . DB 를 활용한 봇 개발
- SCT 서비스를 하다보니 비슷한 기능들을 다른 계정으로 해야하는 것들이 생겨나고 있습니다. 
예를 들면 SCTR 에어드롭과 보상 전송입니다. 이 둘은 앞의 시작은 다르지만 결과는 동일합니다. 

  . SCTR 에어드롭 조건에 맞는 유저 검색 -> SCTR 을 전송
  . SCT 보상을 받을 유저 검색 및 보상 계산 -> SCT 전송

- 이 경우 전송에 대한 부분을 항상 다른 코인으로 테스트를 해보고 그 이후에 실제 코인을 적용하여 서비스를 실행시킵니다.
하지만 이것을 DB 를 사용하여 전송을 할때는 모두 해당 DB에 값만 넣으면 실행이 되도록 하면 개발기간 및 테스트에 대한 부담을 훨씬 줄일 수가 있습니다.

   . 전송 토큰, 송신계정, 수신계정, 전송량, 메모를 관리하는 DB 생성
   . 해당 DB 의 값을 전송을 실행하는 봇

- 이를 위해서 일반화된 전송 봇을 개발하기 위해 설계 중에 있습니다. 뿐만 아니라 특정 계정의 클레임, 전송, 스테킹 등 여러개의 계정에 비슷한 동작을 하는 것들을 위와 같이 DB 로 일반화하여 개발할 예정입니다. 이것이 완료가 되면 DB 에 데이터만 넣으면 추가로 개발할 것이 없기에 앞으로 동일한 건에 대해서는 개발이 필요없으니 중요한 작업이 될 것 같습니다.

![](https://ipfs.busy.org/ipfs/QmUKxtLW5JEnqaaAnwiLc9kFK1BqpcMGoFKTF7JLKcvJqy)

이 외에도 해야할 안정화 작업은 차근차근 진행할 예정입니다.
10월 말까지 최대한 계획했던 안정화 작업을 마무리 지었으면 하는 바람입니다. ^^