SCOT Bot 과 각 Token 홈페이지와의 관계
안녕하세요 @realmankwon입니다.
오늘 장시간동안 scot bot의 이상이 있었습니다.
그로 인해 payout 금액이 현저히 줄어든 경우가 발생했습니다.
관련해서 많은 분들이 원인이 뭔지에 대해서 궁금해 하고 있고 이런저런 추측을 하고 있습니다.
저 역시도 scot bot의 소스를 보지도 못했고 확실하게 어떤 메커니즘으로 운영이 되는지를 본 적은 없기 때문에 그동안의 개발 지식으로 짐작하는 수 밖에는 없는 상황입니다.
그래서 제가 생각하는 steem 기반 token 들과 scot bot 과의 관계에 대해서 간략하게 정리를 해 보았습니다.
일단 크게 2 부분으로 나눌 수 있을 것 같습니다.
첫번째는 스팀잇의 정보를 주기적으로 확인하면서 scot db 혹은 scot 별도의 blockchain으로 정보를 저장해 주는 scot bot.
두번째는 scot bot 이 저장한 정보를 사용자들이 볼 수 있도록 만들어진 홈페이지.(제가 수정하고 있는 nitrous 소스)
scot bot 의 경우는 오픈소스로 공개를 했는지는 모르겠으나 공개를 했다고 하더라도 관리하고 있는 db 혹은 blockchain에 직접 값을 넣을 수는 없도록 되어 있을겁니다.
왜냐하면 그렇게 될 경우 저같은 개발자는 그 소스를 받아서 제가 유리한 쪽으로 변경한 후 자체적으로 돌려버리면 저는 token 재벌이 될 수 있습니다.
때문에 저 영역은 각 token 운영진이 관리하는 소스로 변경할 수 없는 영역입니다.
다음으로 저희가 보고 있는 각각의 web server에서 별도로 돌리고 있는 token 홈페이지는 얼마든지 변경이 가능합니다.
이 소스는 https://github.com/steem-engine-exchange/nitrous 에서 모든 사람들에게 공개가 되어 있습니다.
sct, aaa, spt 등의 token 들은 저 소스에서 가지를 쳐서 소스를 변경한다는 의미로 branch를 하여 소스를 변경하였고 이것을 각 운영진이 구성한 web server 에서 구동하여 홈페이지 형태로 볼 수 있게 되어 있습니다.
제가 도식화한 제일 오른쪽 부분이 github에서 볼 수 있는 branch 입니다.
오늘과 같은 scot bot 의 장애가 생기면 각각의 token 홈페이지의 접속은 아무런 문제가 없지만 voting, claim, payout 등의 token의 운영 부분은 제대로 동작하지 않을 것입니다.
반대로 scot bot의 장애는 없지만 token의 웹서버에 문제가 발생하면 홈페이지 접속 자체가 안 되지만 예민한 문제는 생기지 않을 것입니다.
저는 12년 정도 개발을 하면서 시스템을 유지보수 중에 있는데 상식적으로 생각해 봐도 현재의 장애는 가벼운 문제는 아닌 듯 합니다.
저 세계적으로 서비스되고 있는 시스템에서 어떤 이유에서건 소스의 수정이나 정책의 변경이 있으면 사전에 공지를 하고 이것을 적용해야 한다고 봅니다.
또한 그 이전에 철저한 test를 통해서 장애가 발생하지 않도록 해야 하며 장애가 발생하였을 때도 롤백을 할 것인지 아니면 장애 발생시 즉각적인 조치를 취할 것인지 조치는 어떤 방식으로 할지 등의 시나리오를 작성해야 된다고 생각이 됩니다.
개발 능력은 뛰어나 보이지만 유지보수를 하는 능력은 조금은 떨어지는 것이 아닌가 생각해 봅니다.
제 설명에 잘못된 부분이 있것나 설명이 부족한 부분은 댓글로 얼른 알려주세요 ^^
스팀엔진 덕분에 운영진들이 더 힘든 하루인 듯 합니다.
보상이 적게 나온 것도 잘 해결되길 바래봅니다.
남은 휴일 잘 보내세요~!
심층분석을 올리려다가 먼저 리스팀부터 합니다. 고생 많으십니다. 홧팅!
오 심층분석 기대하겠습니다 ^^
그러게요... 이정도 시스템이면 따로 테스트한 후 적용되야 할텐데...
뭔가 바뀔때마다 혼란이 많이 생기는것 같네요.
전 세계적인 서비스를 하면서 이런 실수를 연달아 한다는 건 납득이 가지 않습니다.
어떤 방법으로든 반드시 공지가 있어야 할 듯 합니다.
스콧 봇이 발전하는 만큼 오류도 많아지는 느낌입니다;;
음... 이건 개발자가 꼼꼼히 못해서 일어나는 휴먼 에러인 듯 합니다.
test suite를 돌려가면서 해야할 듯 한데 그러지 못하는 듯 하네요.
"내일부터 무슨 시스템의 유지보수가 대략 며칠 동안 진행이 될 예정이다" 정도의 사전 공지만 이루어져도 좋을 것 같습니다. 개발 진행 속도가 빠른 것은 좋지만, 사용자들이 혼란을 겪지 않도록 사전 고지를 해주면 좋을 것 같네요 ㅠㅠ
개발 진행 집중도 좋겠지만
영향도 분석하여 사전 공지 항상 절실합니당~!
Posted using Partiko Android
매우 공감합니다... 그런데 작은부분 하나하나 다 하기 힘들다는 선무님의 이야기도 매우 공감하고..
어느정도 선이 있으면 좋을 것 같은데 말입니다 ㅠㅠ
지당하신 말씀입니다.
그 정도 공지는 충분히 가능할 것 같은데 왜 하지 않는지 모르겠네요 ㅜㅜ
오류 원인이 위드캐쉬 자리수 오버플로우로
bigint 에서 number로 데이타 타입 전환했다고 합니다~
Posted using Partiko Android
그렇군요.
그런 건이면 정말 민감한 사항인건데... 그걸 공지도 없이 테스트도 없이 했다는게 믿어지지 않는군요 ㅜㅜ
그러게요~ 중단 된 후 복구 된 다음에 올라오는 개발자 포스팅이 야들 참 막나가는구나 생각 들게 만들더라구요~ ㅠ
Posted using Partiko Android
저도... 오류 정도가 아니라 대형 사고라고 생각해요.
그런데 안 고치고 있다는 게 더 초대형 사고인 거고요.
초초초초초대형 사고죠...ㅜㅜ
잘 읽고갑니다 realmankwon 님^^
감사합니다 ^^
훌륭한 분석 잘 보았습니다.
@realmankwon님과 같은 분이 향후 라운칭될 ZZAN과 함께 숙제를 풀어나갈 고민을 같이 할 수 있으면 좋겠네요!
워낙 수정할 사항이 많고 시간은 부족하고 하다보니 바로 적용해 버린것 같은 느낌이 ...
커밋하고 테스트하고 적용하고 적용된것 다시 확인 하고 ... 단계적으로 할건 많은데 인력이나 시간 등 여러 리소스가 부족한게 아닐까 싶네요
아무쪼록 탄탄한 시스템으로 성장하길 바랍니다