레이블이 sw engineering인 게시물을 표시합니다. 모든 게시물 표시
레이블이 sw engineering인 게시물을 표시합니다. 모든 게시물 표시

[컴] google SRE 팀이 20년간 사이트를 운영하면서 얻은 교훈

구글 / 레슨 / lesson /

google SRE 팀이 20년간 사이트를 운영하면서 얻은 교훈

20년전 구글:

  • 2개의 소규모 데이터 센터, 각각 수천개 서버를 보유
  • 서버끼리는 한쌍의 2.4G network link 로 ring 연결
  • private cloud 를 운영
  • Assigner, Autoreplacer, Babysitter 같은 python script 로 운영
  • 이 script 들은 각각의 서버이름들로 가득찬 config file들을 기반으로 동작했다.
  • 작은 DB 기기가 있었다. 이 DB는 개별서버에 대한 정보를 체계적이고, 안정적이게(durable) 유지하는데 도움을 줬다.
  • 다음 이유로 script들과 config 들을 사용했다.
    • 일반적인 문제들을 자동으로 해결하기위해
    • 작은 서버 무리를 관리하는데 필요한 수작업을 줄이기 위해

현재:

2016년 Youtube global outage 에서 얻은 교훈

YouTube’s distributed memory caching system 으로 글로벌한 중단(global outage)를 15분간 경험으로 얻은 3가지 교훈

  1. The riskiness of a mitigation should scale with the severity of the outage (장애 완화조치의 위험성은 장애(outage)의 심각성에 비례한다.)
    • SRE 팀은 장애를 해결하기위해 한 조치가, 장애 자체보다 더 큰 위험을 초래한 경험이 있다.
    • 유투브 팀이 장애완화로 load-shedding을 했는데(일부 서비스나 기능을 의도적으로 중단시키는 방법), 이것이 장애를 해결하진 못하고, 이로 인해 연쇄적인 문제가 터졌다.
    • 장애상황에서는 모니터링과 상황의 심각성을 평가해야만 하고, 그리고 나서 장애의 심각성과 비슷한 수준의 위험을 갖는 장애완화조치(mitigation path)를 선택해야만 한다.
  2. Recovery mechanisms should be fully tested before an emergency (복구 절차들은 긴급상황전에 완전히 테스트돼야만 한다.)
    • 복구절차에 대해서 다음사항에 대해 테스트해라. 이것이 이 행동이 수행될때 위험을 줄여줄 것이다.
      • 그것이 원하는대로 동작하는지
      • 당신이 그것을 어떻게 사용하는지 아는지
    • 이번 중단을 겪고, 복구과정 testing 에 2배의 시간을 할당함.
  3. Canary all changes (모든 변화들을 미리 점검해라)

Google calendar 이슈 에서 얻은 교훈

  1. Have a “Big Red Button” (큰 빨간 버튼을 가져라)
    • 잠재적으로 위험한 작업을 하기전에 어떤것이 빨간 버튼들이 될 지 파악하는것이 중요하다.
    • 예를 들어, 어떤 것을 작업했는데, 그것이 퍼지기전에 plug 를 뽑아서 막을 수 있다면 그것이 빨간버튼이 되는 것이다.
    • Generic mitigations – O’Reilly
  2. Unit tests alone are not enough - integration testing is also needed (유닛테스트들 만 하는 것은 충분치 않다. 통합테스트 또한 필요하다.)
    • 유닛테스트는 runtime 환경과, 모든 production 의 요구사항을 그대로 복제해서 하는 테스트가 아니다.
    • 우리는 통합테스트들을 cold start 를 수행할 수 있다는 것을 확인하는데 사용할 수 있다.
    • 우리가 원하는 대로 동작하는가?
    • 구성요소들(components)가 우리가 원하는대로 함께 동작하는가?
    • 이 component 들이 성공적으로 우리가 원하는 system을 만드는가?
    • 우리의 test들이 실제 사용방법을 따르지 않았다. 그결과로 많은 테스트들이 변경이 실제로 어떻게 수행될지 평가하는데 도움이 되지 않았다.

2017년 2월 사건의 교훈

OAuth token 이 사용불가 되자 많은 기기가 logout 하고, OnHub 및 google wifi 기기가 공장초기화를 수행했다. 수동 계정복구 요청이 10배 급증.

  1. COMMUNICATION CHANNELS! AND BACKUP CHANNELS!! AND BACKUPS FOR THOSE BACKUP CHANNELS!!!

    • Google Hangout과 , Google Meet 로 사건을 관리하려 했지만, 사람들이 log out 돼서 연락이 안됐다.
    • 테스트가 된 의존성없는 대체 소통 채널들을 가져야만 한다.
    • 이 사건은 graceful degradation | Google - Site Reliability Engineering 에 대한 더 나은 이해를 하게 해줬다.
  2. Intentionally degrade performance modes (의도적인 성능저하 모드)

    • 모든것이 작동하지 않더라도, 최소의 기능이 꾸준히 제공되도록 하는 것이 때로는 더 일관된 사용자경험을 제공할 수 있기도 한다.
    • 신중하고, 의도적인 저하된 성능모드를 구축했다. 성능저하도 gracefully 하게 이뤄져야 하고, 예외적인 상황에서도 동작해야 한다.

자연적인 재해, 또는 사이버 공격등을 막으려면:

  1. Test for Disaster resilience (재해 복원력 테스트)
    • Resiliance testing 은 오류, 대기시간 또는 중단이 발생해도 서비스나 시스템이 유지될 수 있는지 확인
    • recovery testing 은 완전한 shutdown 된 이후에 다시 homeostasis(항상성) 로 돌아갈 수 있는지를 확인
    • 둘 다 사업의 연속적인 전략에 중요한 부분이 돼야 한다.
    • 유용한 활동: 다같이 앉아서 만약의 사태가 일어났을때 시나리오를 살펴보는 것
  2. Automate your mitigations (재해복구 자동화)
    • 2023년 3월, 몇몇 데이터 센터에서 여러 네트워킹 장치에 거의 동시에 장애가 발생하여 광범위한 패킷 손실이 발생
    • 이런 경우 복구하는 동작을 자동화 해놓으면, MTTR(mean time to resolution, 해결평균시간)을 줄일 수 있다.
    • 만약 특정 사건이 일어날때 왜 그 복구방법을 자동으로 실행할 수 없나? 때론 복구를 먼저해서 사용자영향을 피하고, 주요원인을 저장하는 것이 낫기도 하다.
  3. Reduce the time between rollouts, to decrease the likelihood of the rollout going wrong (배포(rollout)들 간의 시간을 줄여서 배포(rollout)가 잘못될 가능성을 줄인다.)
    • 2022년 3월, 결제 시스템의 광범위한 중단
    • database field 한개를 지웠는데, 그것이 문제가 됨.
    • 그 field 를 사용하는 모든 code를 그전에 지웠기 때문에 문제는 없었다.
    • 시스템의 한부분의 rollout 이 느렸는데, 그로인해 그 filed 가 live system 에서 사용되게 되었다.
    • 여러 구성요소가 있는 복잡한 시스템에서 이런 배포사이에 긴 지연이 있으면, 변경사항에 대한 안정성을 추측하기가 어려워 진다.
    • 빈번한 rollout 이 이런 종류의 실패에 대한 갑작스러운 놀람을 줄여준다.
    • Use Four Keys metrics like change failure rate to measure your DevOps performance | Google Cloud Blog
  4. A single global hardware version is a single point of failure (하나의 글로벌 하드웨어 버전은 실패 지점이 된다.)
    • 중요한 기능을 하는 기기가 특정 모델을 사용하는 것이 좀 더 간단한 운영과 유지를 하게 해주긴 한다.
    • 그러나 그 모델이 문제가 있을 경우, 중요한 기능은 더이상 동작하지 않는다.
    • 2020년 3월, 네트워킹장비가 발견되지 않은 zero-day bug 가 있었는데, 트래픽패턴의 변화가 생겨서 그 버그가 터져나왔다.
    • 네트워크 모두에 같은 모델과 버전의 기기들이 사용중이었어서, 상당한 지역적 중단은 발생했다.
    • 높은 우선순위 트래픽을 잘 동작하는 다른 기기로 전달해주는 여러개의 network backbone 들이 존재해서 전채적인 중단을 막을 수 있었다.
    • diverse infrastructure 를 유지하는 것은 그 자체로 비용이 들지만, 이것이 완전한 서비스 장애를 벗어나게 해줄 수 있다.

See Also

  1. Lessons Learned from Twenty Years of Site Reliability Engineering | Hacker News : 다양한 경험과 관련된 이야기들
  2. Building Secure and Reliable Systems
  3. > Automate your mitigations Think long and hard about this one. Multiple times i… | Hacker News : 자동화된 복구처리가 가져다 주는 복잡성과의 균형을 잡아야 한다.

[컴][swe] 일할 때 대면이 필요한 이유

대면근무 좋은 점 / 오프라인 근무 / 온라인 근무 단점 / 원격 근무 리코트 / 원격보다 사무실 근무 / ms

일할 때 대면이 필요한 이유

다음 링크는 사무실근무에 대한 마이크로소프트 워크랩의 연구 결과이다. 이글은 대한 번역, 정리이다.

하이브리드 역설:

  • 2021년 Work Trend Index (The Next Great Disruption Is Hybrid Work—Are We Ready?) 에서 하이브리드 역설(hybrid paradox)을 발견
    • 70% 이상이 유연한 근무를 원했고
    • 65% 이상이 팀과 더 많은 대면 시간을 갈망
  • 새로운 연구
    • 사람들이 사무실에 있는 일수보다, 중요한 순간을 만드는 것이 중요

대면시간(in-person)이 가장 유익한 중요한 3가지 순간들:

  1. 팀 응집력 강화
  2. 새로운 role, 팀, 회사에 대한 시작(Onboarding)
  3. project 의 시작(kick off)

1. 팀 결속력 강화

  • Dawn Klinghoffer, 마이크로소프트의 people analytics 의 책임자
  • 코로나 이전에는 회사의 61% 의 팀들이 같은 위치에 있었다.
  • 현재는 27% 만이 같은 위치에 있다.
  • 최신 마이크로소프트 직원들 대상으로 설문조사
    • 93%의 직원들이 위치에 상관없이 팀으로 협력할 수 있다고 확신
    • 동료와의 연결품질을 중립또는 부정적으로 이야기한 직원의 의견을 보면,
      • 그중 29%는 remote work 가 의미있는 연결과 관계들을 만드는 것을 어렵게 한다고 말했다.
    • 회사에 오는 직원들은 그냥 협력이 아니라 연결에 보낼 시간을 찾고 있다는 것을 알 수 있었다.
    • 팀의 성공을 위해 회사가 제공해야 할 대면 활동이 무엇일까라는 질문
      • 그중 1위를 차지한 대답(37%)가 사회적 관계와 팀 구축활동에 관한 것이었다.

9월 2022 Work Trend Index :

  • 85%의 직원이 동료들과의 사회적관계를 맺기위해 회사로 가고 싶어했다.
  • 또한 팀의 유대감을 재구축하려는 열망으로 가고 싶어했다.


  • 대면 시간은 개개의 직원에게 더 넓은 팀과 조직 의 성공에서 자신이 수행하는 역할을 상기시켜 줄 수 있다.

Work Trend Index report 에서

  • 직속팀원과 긍정적관계를 맺는 직원
    • 더 나은 삶(wellbeing)을 보여준다.
    • 더 높은 생산성을 보여준다.
    • 이직을 할 가능성도 더 낮다.
  • 외부의 네트워크 강화도 중요
    • 직속팀원 이외의 사람과 긍정적인 관계가 있으면,
    • 회사에 대해 더 만족하고
    • 업무에 더 만족하고
    • 직장 스트레스에 대해 더 긍정적인 생각(outlook)을 가지고 있다고 한다.

2. 새로운 역할, 새로운팀, 새로운 회사의 시작

  • 시작할 시점에 관리자나, 같이 onboarding 하는 친구를 만나면, 명확한 작업을 더 쉽게 만든다.
  • 90일이내 관리자를 만난 직원은 90일이내에 관리자를 못만난 직원보다,
    • 피드백을 얻고
    • 팀의 조언을 구하고
    • 동료와 강력한 관계 구축
    • 어려운 문제논의할 때 지원받을 가능성이 더 높았다.
  • onboarindg buddy 를 90일이내 만나는 것도 좋은 영향을 줬다. (새로운 팀으로 이전을 도와주는 팀메이트)
    • 피드백을 얻을 가능성이 높다.
    • 팀으로 부터 소속감 느낄 확률이 높다.
    • 팀으로 부터 믿음을 받을 확률이 높다.
    • 그들이 영향을 미치는 방법이 명확하다고 보고할 가능성이 높고,
    • 그것을 위한 도구도 가지고 있다고 보고할 가능성이 높다.
    • 그러나 다음 분야에서는 의미있는 점수를 얻지 못했다.
      • 그들이 원하는 지원을 찾거나, 그들의 조직의 비젼을 이해하고나, 그들의 이해관계자를 아는 것들
  • 새로운 사원이 ‘관리자’ 및 ’팀원’과의 신뢰를 더 빨리 쌓으면
    --> 더 빨리 팀과 회사의 생산적인 기여자가 된다.
  • 사원이 마찰을 줄이면서 업무와 우선 순위를 이해하는 데 도움이 된다.
    • 가까운 안내를 받을 수 있고,
    • 즉각적인 피드백
    • 도움, 명확함, 문화(tacit knowledge)에 대해 쉽게 접근할 수 있다.
  • 신입사원은 그들이 정기적으로 같은 장소에서 그들의 팀동료와 일할 때 좀 더 활기를 느꼈다.
  • 대면시간(in-person time) 회사 규범(company norms)과 팀 활력(team dynamics)을 관찰할 수 있는 기회를 제공
    • 이것이 신입사원에게는 특히 중요할 수 있다.
  • 관리자를 초기에 만나는 것은 좋은 결과를 내는데 도움을 주지만, 이후엔 주기적으로 면담을 할 필요가 없다.

3. 프로젝트 시작

  • onboarding 과정에서 대면시간에 의해 얻는 이점과 같은 좋은 점이 있다.
  • 프로젝트 라이프사이클의 초기단계에서 유용한다.
  • Microsoft 365 Copilot project 킥오프는 대면으로 진행됐다.
    • 물리적 근접성이 동료가 자신을 이해한다고 느끼는데 도움이 된다.
    • 누구나 다른 사람이 자신의 말을 듣는 다는 느낌을 좋아한다. –> 옆에서 이야기할 때 이 느낌을 받기가 더 쉽다.
  • 상호 신뢰와 조율이 이루어지면 창의적인 아이디어가 샘솟는다.
    • 혁신을 이으키는 데 도움을 주고, 틀에 박히지 않은 사고를 촉발하는 데 도움을 준다.
    • 연구에서, 대면그룹이 같은 시간동안 가상그룹보다
      • 18% 더 많은 창의적인 아이디어를 냈다.
      • 14% 더 많은 아이디어를 냈다.
  • 프로젝트 초기에 만나는 것은 좀 더 효과적으로 다음의 것들을 공유할 수 있게 해준다.
    • 문화(tacit knowledge),
    • 명확성(get clarity),
    • 각자의 역할 정립(establish individual roles),
    • 노력을 조율(coordinate their efforts)

요점

  • 원격 근무는 대면 근무와 마찬가지로 이점이 있다.
  • 팀마다 다르지만 한 가지 분명한 것은 이러한 균형을 찾는 데는 의도적인 접근이 필요하다
  • 팀에서 수행하는 업무 유형을 고려하고 직접 모여야 하는 주요 시점이나 이유를 결정해야 한다.

Reference

  1. In the Office, It’s All About Moments That Matter

[컴] '빈 서트'의 엔지니어들을 위한 커리어 조언

인터넷의 아버지 / 조언 / 시니어 엔지니어 / 조언 / 일을 잘하는 법 / 명언 / 태도 / 자세

빈서트의 엔지니어들을 위한 커리어 조언

  • “If you really want to do something big, get help, and preferably from people who are smarter than you are.”
  • “만약 정말로 큰 일을 이루고 싶다면, 도움을 받아라. 가능하면 너보다 똑똑한 사람들로부터 받아라.”
  • “Be humble, because unless you approach things with the understanding that you really don’t know exactly how to make it all work, you may overlook possibilities.”
  • “겸손하라. 당신이 모든 것이 어떻게 작동하는지 정확히 모른다는 것을 이해하고 접근하지 않으면, 가능성을 놓칠 수도 있다.”
  • “Listen to other people. I tell my engineers that if they know I’m about to do something stupid, they have to tell me, so I don’t do it. And if they knew and didn’t tell me, that’s going to be reflected in their end-of-year fitness report. When you’re in a position of responsibility and authority, people may assume you’ve already figured out where the hazards are, but you may not have.”
  • “다른 사람들을 들어라. 내 엔지니어들에게 그들이 내가 어떤 어리석은 짓을 하려는 것을 안다면, 반드시 내게 말하라고 한다. 그래서 내가 그것을 하지 않도록 합니다. 그리고 만약 그들이 알았는데 말하지 않았다면, 그것은 그들의 연례 평가에 반영될 것이다. 책임과 권한을 가진 위치에 있을 때, 사람들은 네가 이미 위험지역을 파악했다고 가정할 수 있지만, 실제로는 그렇지 않을 수 있다.”
  • “Try hard to stay on good terms with everybody. Civility is an important property, and burning bridges is generally a bad idea; you never know who you’re going to work with again, who you might work for, or who might work for you.”
  • “모두와 좋은 관계를 유지하기 위해 노력하라. 정중함(Civility)은 중요한 가치이며, 다리를 태우는 것은 일반적으로 좋지 않은 생각이다. 너는 미래에 누구와 함께 일할지, 누구의 일을 할지, 또 누가 너를 위해 일을 할 지 알 수 없다.”
  • “You can learn something from virtually everybody. One example: I was being driven in a limousine in Palm Springs by a white-haired guy. And I remember thinking, ‘This poor guy, it’s too bad. Here he is driving a limo. It’s nine o’clock at night. He ought to be just out there on the links playing golf and having a nice time.’ We struck up a conversation, and I find out that he actually did retire—from being the chief financial officer of one of the largest insurance companies in Chicago. He got bored playing golf, so he decided to drive a limo three times a week because he knew he was going to meet interesting people.”
  • “거의 모든 사람으로부터 무언가를 배울 수 있다. 한 가지 예를 들자면: 나는 팜스프링스에서 흰머리 노인이 운전하는 리무진에 타고 있었다. 그리고 ’가난한 사람이 참 안됐다. 여기서 리무진을 운전하고 있네. 밤 9시인데. 그는 골프를 치며 즐거운 시간을 가져야 하는데’라고 생각했다. 우리는 대화를 나누면서 알게 되었는데, 실제로 그는 최대 규모의 시카고 보험 회사의 최고 재무 책임자로부터 은퇴한 사람이었다. 그는 골프를 치는 것이 심심해서 일주일에 세 번 리무진을 운전하기로 결정했다. 왜냐하면 그는 흥미로운 사람들을 만나게 될 것이라는 것을 알고 있었기 때문이다.”

see Also

  1. 상위 1% 엔지니어의 7가지 간단한 습관 | GeekNews

Reference

  1. Vint Cerf’s Career Advice for Engineers - IEEE Spectrum

[컴][swe] Clockwise 의 software engineering 보고서

swe / 엔지니어링 / 일을 집중하는 법 / 일에 집중 / 시간을 확보하는 법 / 미팅을 줄이는 법 / 회의를 줄이는 법 /

Clockwise 의 software engineering 보고서

참고할만 하다. 개발자가 집중할 시간(여기서는 2시간 이상의 시간을 이야기한다.)이 기업이 커지면서, 더 많은 회의가 생기고 그로인해 쓸 수 있는 시간이 줄어든다는 내용이다. 그것을 coordination tax 라 표현하는 듯 하다.

Focus time 을 더 만들기 위해 쪼개지는 시간들을 모으는 방법을 이야기한다.

The benchmarking data in this report is derived from more than 1.5 million meetings from more than 80,000 users who self-reported that they work in Software Engineering. The data was from May 2021 to May 2022. All data was aggregated, anonymized, and contained no personally identifiable information. Clockwise defines Focus Time as a 2+ hour block of uninterrupted time. In the report, small companies = 1-249 employees, medium companies = 250-999, and large companies = 1,000+ employees. The Engineering Manager Focus Time survey was conducted in January 2020 from a survey of 152 self-reported Engineering Managers.

이 보고서의 벤치마킹 데이터는 소프트웨어 엔지니어링 분야에서 일하고 있다고 자체 보고한 80,000명 이상의 사용자로부터 150만 건 이상의 회의에서 나왔다. 데이터는 2021년 5월부터 2022년 5월까지였습니다. 모든 데이터는 집계되고 익명 처리되었으며 개인 식별 정보가 포함되지 않았습니다. Clockwise는 Focus Time을 방해받지 않는 2시간 이상의 블록으로 정의합니다. 보고서에서 소기업 = 직원 1~249명, 중기업 = 250~999명, 대기업 = 직원 1,000명 이상입니다. 엔지니어링 관리자 Focus Time 설문 조사는 2020년 1월에 152명의 self-reported 엔지니어링 관리자들을 대상으로 실시되었습니다.

screenshots

See Also

  1. Where Did All The Focus Time Go? Dissecting 1.5 Million Meetings w/ Clockwise’s VP of Engineering, Dan Kador

Reference

  1. Software Engineering Meeting Benchmarks - 2022

[컴][보안] AWS 와 ISMS

 

인증 /

AWS 와 ISMS

위의 글에 있는 내용 일부 정리

  • HW방화벽 설치 부분을 AWS 특정 가입정보를 안내에 따라 캡쳐해서 신고한 경우

  • ISMS 는 어느정도 해결됐다?

  • K-ISMS – Amazon Web Services(AWS)

AWS의 K-ISMS 인증은 K-ISMS 인증을 받으려는 고객에게 어떤 이점이 있습니까?

공동 책임 모델에 따라 AWS는 K-ISMS 인증을 통해 클라우드의 보안(Security of Cloud)을 입증하였습니다. 이는 고객이 자체 K-ISMS 인증 절차에서 클라우드에서의 보안(Security in the cloud)과 관련된 영역에 리소스를 집중할 수 있도록 합니다.

이 Quick Start는 ISMS-P 제어 요구 사항을 충족하는 보안 및 관리 서비스를 포함하여 개인 정보 및 정보 보안 관리 시스템(ISMS-P)을 배포합니다. 여러 Amazon Web Services(AWS) 서비스를 결합하여 일반 다중 계층 웹 애플리케이션을 지원하는 방법을 보여줍니다.

See Also

  1. (비공인)네이버 클라우드 ISMS-P 인증심사 통과하기

[컴] 2022년 11월 카카오 서비스 장애 내용

카톡 중단 이유 / 화재 사건 / 사고발생 이유 / 중단된 이유 / 이중화 /

카카오 서비스 장애 내용

정부의 디지털서비스 장애 조사결과 발표

ref. 1 의 내용을 발췌

  • 카카오 계열사의 주요서비스(카카오톡, 카카오티 등) 최대 127시간 33분간 장애 발생

  • 카카오는 서비스 기능을 5개의 레이어로 구분*하고 판교 데이터센터(Active 역할)와 기타 센터 간 동작(Active)-대기(Standby) 체계**로 이중화했으나, 이번 사고 시 대기(Standby) 시스템이 제대로 동작하지 못하였다.

* 애플리케이션, 서비스 플랫폼, 운영 및 관리도구, 데이터베이스, 기반시설 설비 레이어
** 동작 서버 작동 불능시 대기중인 대기 서버를 가동하여 서비스 제공하는 방식

  • 대기 서버를 동작 서버로 만들기 위한 권한관리 기능인 ’운영 및 관리도구*’가 판교 데이터센터 내에서만 이중화되어있을 뿐 타 데이터센터에 이중화되어있지 않아, 판교 데이터센터의 동작 서버 작동 불능 시 서비스 장애 복구가 지연되었다.

* 서비스의 가동과 운영 등을 제어하는 기능과 이러한 기능에 대한 접근 및 관리를 수행하는 도구

  • 또한,‘애플리케이션’, ‘서비스 플랫폼’ 레이어에서도 이미지·동영상 송수신 시스템 등 일부 서비스 구성 요소가 데이터센터 간 이중화되어 있지 않아 복구에 상당 시간이 소요된 원인이 되었다.

  • 카카오톡, 다음 등 카카오 서비스 대부분의 핵심기능이 판교 데이터센터에 집중되어 있어 판교 데이터센터 사고 시 카카오 대부분 서비스가 즉각 영향을 받게 되었다.

  • 특히, 여러 서비스의 구동 초기단계부터 필요한 ’카카오인증’과 같은 핵심기능도 판교 센터에 집중되어, 여러 서비스 전반에 광범위한 영향을 미친 원인이 되었다.

  • 카카오는 장애 탐지·전파·복구 전반에 걸쳐 기본 절차를 정의하고 있으나, 각 단계별 체계화 및 자동화가 미흡하였다.

    • ※ (예) 사내 전파 수단 준비 미흡, 이용자 공지채널(트위터, 페이스북)의 낮은 접근성 등
  • 일부 서버, 연결망 등 오류에 대비한 재난 대비 훈련 등 조치는 하였으나, 1개 데이터센터 전체가 일시에 불능이 되는 대형 재난상황에 대해서는 대비가 부족하였다.

  • 한편, 카카오는 10.19. ~ 11.6. 간 10만 5,116건의 피해를 접수하였으며, 이중 유료 서비스에 대한 피해는 14,918건, 금전적 피해를 언급한 무료 서비스는 13,198건이 접수되었다.

‘if kakao’ keynote 에서 밝힌 내용

  • https://youtu.be/mG17fY4RhHw?t=8m14s : 캐시서버, 오브젝트 storage(카카오톡 사진전송) 의 2중화가 완벽하지 않았다.
  • https://youtu.be/mG17fY4RhHw?t=8m35s : 다른 region 으로 자동전환해주는 시스템의 2중화가 안됐다.
  • https://youtu.be/mG17fY4RhHw?t=9m : ‘운영관리도구’(컨테이너 이미지를 저장,관리하는 시스템등), ’모니터링 시스템’의 2중화가 안됐다.
  • https://youtu.be/mG17fY4RhHw?t=9m24s : 뒤늦게 살리면서, 가용자원의 확보가 어려웠다.(me: 카카오톡 같은 거대한 시스템에 대한 자원확보는 쉽지 않은 일이긴 할듯.)
  • https://youtu.be/mG17fY4RhHw?t=10m10s : 장애 복구 인력과 컴퓨터자원 부족
  • https://youtu.be/mG17fY4RhHw?t=10m35s : 장애 대응을 위한 소통채널에 혼선. 사내 커뮤니케이션은 카카오톡, 모니터링 채널은 카카오 워크 사용했는데, 이것을 사용할 수 없는 시점에 사용할 비상 커뮤니케이션 채널이 정해진게 없었다.
  • https://youtu.be/mG17fY4RhHw?t=11m : 재해 초기의 컨트롤 타워가 없었다. ‘전체적인 조율’, ‘협업을 지원’ 하기 힘들었다.
  • https://youtu.be/mG17fY4RhHw?t=15m31s
    • 카카오, 판교 데이터센터에만 3만2천대 서버를 사용
    • 이번에 판교 데이터 센터의 전체 서버가 다운됨.
    • --> 모니터링, 분석 툴을 사용할 수 없게됨.
    • --> 장비 모니터링, ’장애 탐지’가 원활히 이뤄지지 못했다.(정보를 조회하는 것등이 원활하지 못했다.)
  • https://youtu.be/mG17fY4RhHw?t=17m4s
    • 카카오에서 사용중인 data관련 서비스들
      • MySQL, PostgreSQL, Oracle : 2중화 잘되어 있었다.
      • MongoDB : 2중화 잘되어 있었다.
      • HBase, Druid, Hadoop cluster : Druid 는 클러스터 다중화 작업, Hadoop cluster 데이터센터간 노드분산 확대 필요
  • https://youtu.be/mG17fY4RhHw?t=18m9s
    • 2중화가 잘안된 운영관리도구들
      • 사내 계정 인증 서버
      • 소스 관리 도구
      • 앱 배포 도구
      • 위키, 지라
  • https://youtu.be/mG17fY4RhHw?t=18m56s
    • 2중화가 잘 안된 플랫폼
      • 자체 클라우드
      • 엘라스틱서치 플랫폼
      • 레디스, 카프카 클러스터 운영
    • region 이 동작안할 때에 대한 대비가 없었다.
    • 수많은 서비스들이 한꺼번에 다운된 경우 어떤 순서로 restart 를 해야되는지에 대한 가이드가 없었다.
    • 엘라스틱서치, 레디스, 카프카 모두 전체중 약 1/3 가량의 클러스터에서 통신장애가 발생
  • https://youtu.be/mG17fY4RhHw?t=20m20s
    • 카카오 클라우드
      • 이중화 구성이 되어있던 부분
        • 컨테이너 오케스트레이터
        • 컨테이너 이미지 저장소
      • 이중화 구성이 안되어있던 부분
        • 주요 메타정보 저장소 : 이것이 동작하지 않아서 한동안 데이터의 위치를 찾을 수 없었다.
        • 보안키 저장소
        • 오브젝트 스토리지
        • 클러스터 모니터링 도구
  • https://youtu.be/mG17fY4RhHw?t=21m5s
    • 다음(daum) 첫화면
      • DB나 캐시서버등의 기반시스템이 HA 로 구성되어 있다.
      • 컨테이너 오케스트레이터위에서 기동, region 간 2중화는 되어 있다.
      • 각 노드별로 health check 에서 이상있는 노드를 자동으로 제외하도록 되어 있다.
      • HA 구성이 되어 있었지만, 정상작동하지 않았다.
      • 그래서 health check 가 fail 되고, 모든 app 이 disabled 돼서 오류가 발생했다.
      • 운영관리도구가 동작안해서 파악도 안됐다.
      • 다른 region 의 cache server가 동작한 이후에 서비스가 정상화 됐다.
    • 카카오톡 서버, 카카오 로그인 등의 서비스에서의 문제점
      • 서비스 간 의존성 문제
      • 서버의 불완전한 failover 구성
      • 트래픽이 쏠림에 따른 대응 부족
      • 충분치 않았던 장애 시나리오
      • 서버를 기동시켰을 때, 의존성이 있는 서버가 떠 있지 않으면 기동시킬 수 없는 서버가 있었다.
      • failover 가 되어도 이것이 health check 등이 동작하는 것을 전제로 만들어져 있어서, 동작 이상을 감지하는 서버의 문제가 발생해서 failover가 제대로 동작하지 않았다.
      • 한쪽 서버로 traffic 이 몰려서, 응답속도가 느려지고, health check에 실패하는 경우도 생겼다. 이 경우 orchestrator 가 자동으로 중지를 시키게 되어 있다. 이렇게 중지된 서버를 다시 run 하려 할 때는 container image 저장소의 장애로 다시 실행을 할 수 없었다.

Refereces

  1. 디지털서비스 장애 조사결과 발표, 시정 요구, 과학기술정보통신부 - 과학기술정보통신부, 2022-12-07

[컴][swe] github issue 를 vscode 에서 notebook 을 이용해서 하기

 

github issue notebooks 사용 / 여러 github issue 를 한번에 보려면 / vscode 에서 이슈관린 / pm project manager / managing / 프로젝트 매니징

github issue 를 vscode 에서 notebook 을 이용해서 하기

vscode 의 extension 중에 ‘GitHub Issue Notebooks’ 가 있다. vscode 에 이 extension 을 깔아보자.

  1. https://vscode.dev/ 로 가자.
  2. extension tab 으로 가서 ‘Github Issue Notebooks’ 를 설치하자.
  3. Menu File –> New File… –> Github Issue Notebook 선택
  4. cell 에 원하는 type 의 query 를 넣는다.

쓸만한 query

아래 링크에서 좀 더 자세한 query 를 날리는 법을 배울 수 있다.

repo:microsoft/vscode is:open

Github 의 repository 에 ipynb file을 upload 하면 rendered view 를 보여준다.

.ipynb 파일을 업로드하면, 그것을 rendering 후 보여준다. 물론 원한다면 raw 도 볼 수 있다.

.ipynb 파일을 공유할 때 의미가 있을 듯 하다.

See Also

  1. Welcome To Colaboratory - Colaboratory : 구글 login 이 필요하다. ref. 2 를 보면, CoLab 은 구글에서 제공하는 무료로 쓸 수 있는 Jupyter notebook server 로 보면 될 듯 싶다. 근데 code 실행시에 GPU 를 사용할 수 있는 듯 하다. 아마 ML 용인듯 싶다.이 CoLab 은 만들어진 notebook 을 google drive 에 저장한다고 한다.

  2. Using Jupyter Notebooks on GitHub: Answers to Most Common Questions - ReviewNB Blog : ReviewNB에 대한 이야기. Github 를 Jupyter Notebook file 에 대한 version control system 으로 사용할 때, 문제점은 diff 를 보면, json 파일 그 자체에 대한 diff 만 제공한다. notebook 의 rendered 된 view 가 아니라. 그래서 diff 를 봐도 차이를 알기 어렵다. 그래서 rendered 된 view 에 대한 diff 를 제공해주는 tool 이 ReviewNB 이다. nbviewer 라는 것도 있다.

Reference

  1. Sample
  2. GitHub - WiktorJ/google-colab-tutorial: Basic tutorial on how to conveniently use Google Colab with Google Drive and Github

[컴][swe] 프로그래밍 가이드 라인

 

프로그래밍 가이드 라인

Zen of python 의 내용은 프로그래밍을 하는 사람에게 유용한 정보라고 생각된다. 특히나 여럿이 해야 하는 대단위 프로젝트에서는 더더욱 중요하다고 생각한다. 그래서 정리를 좀 해본다.

Zen Of Python

Zen Of Python

컴퓨터 프로그래밍 할 때의 가이드라인 같은 것들이 있는데, 그중에 python 을 만들때 영향을 준 가이드라인이라고 한다. 총 19개이다.

이것을 Tim Peter 라는 사람이 1999년 python mailing list 에 올렸다고 한다.

  1. Beautiful is better than ugly. : 아름다운것이 못생긴것보다 낫다.
  2. Explicit is better than implicit. : 명확한 것이 내포된 것 보다 낫다.
  3. Simple is better than complex. : 간단한 것이 복잡한 것 보다 낫다.
  4. Complex is better than complicated. : 구조적으로 복잡한 것이 이해못할정도의 복잡함 보다는 낫다
  5. Flat is better than nested. : 편편한 것이 중첩된 것 보다 낫다.
  6. Sparse is better than dense. : 드문것이 촘촘한 것 보다 낫다.
  7. Readability counts. : 가독성은 중요하다.
  8. Special cases aren't special enough to break the rules. : 특별한 경우들 때문에 규칙을 깨지마라.
  9. Although practicality beats purity. : 실용성이 순수함을 이긴다하더라도 규칙을 깨지마라.
  10. Errors should never pass silently. : 에러들은 절대 조용히 발생하면 안된다.
  11. Unless explicitly silenced. : 명확히 조용하지 않는한, 에러는 조용히 발생하면 안된다.
  12. In the face of ambiguity, refuse the temptation to guess. : 모호한 것이 있을 때, 추측으로 그것을 넘겨짚지 마라.
  13. There should be one– and preferably only one –obvious way to do it. : 그것을 하는 방법이 1개는 있어야만 한다. 가급적이면, 하나만 있어야 한다.
  14. Although that way may not be obvious at first unless you're Dutch. : 만약 당신이 네델란드인이 아니라서, 비록 그것이 처음에는 명확치 않을 수 있을지라도,
  15. Now is better than never. : 이후에 안하는 것보다 지금이 하는 것이 낫다.
  16. Although never is often better than right now. : “전혀 안하는 것”이 종종 “바로지금” 보다 나을지라도, 이후에 안하는 것보다 지금하는 것이 낫다.
  17. If the implementation is hard to explain, it's a bad idea. : 만약 구현을 설명하기 힘들다면, 그것은 나쁜 아이디어다.
  18. If the implementation is easy to explain, it may be a good idea. : 만약에 구현이 설명하기 쉽다면, 그것은 좋은 아이디어다.
  19. Namespaces are one honking great idea – let's do more of those! : 네임스페이스들은 경종을 울리는 좋은 아이디어이다.

See Also

  1. complex vs complicated : complex 는 구조적으로 복잡한것, complicated 는 이해가 안되는 복잡함.

Reference

  1. Wikipedia, Zen Of Python

[컴][swe] IT 인력 채용시 유의해야 할 점

인력 고용 / interviewer / 면접자 /it인력 고용방법 / 팁

IT 인력 채용시 유의해야 할 점

ref. 1 을 보면 다음 내용은 IT 리더 및 채용담당자들과의 대화에서 나온 이야기라고 한다.

  1. 무례한 태도의 신호: Great on paper, rude at interview;
    • 아웃리치(Outreach)의 채용 책임자 제니 랜섬
    • “엔지니어링 조직을 구성한다면 직무를 수행하고 제품을 개선할 수 있으면서도 다른 엔지니어들과 잘 협력하고 다른 조직과 교차 협업할 수 있는 사람들이 필요하다. 필요한 하드 스킬을 모두 갖고 있지만 프로세스 내내 채용 팀 또는 존중하는 태도가 부족한 사람과 면접을 진행한 경험이 있다. 다양한 업무 스타일을 수용하고 인식해야 하지만 다른 이들에 대한 무례는 적색 신호이다. 다행히도, 검증 프로세스를 통해 그 사람이 고용되기 전에 미리 조사할 수 있었다”
  2. 암기한 듯한 대답: Canned answers
    • 아웃리치(Outreach)의 채용 책임자 제니 랜섬
    • 암기한 대답을 사용하는 구직자는 문제의 조짐이다. 암기한 대답은 사려 깊음과 비판적 사고의 부재를 보여준다.
    • “때로는 지원자가 포괄적인 대답을 하는 경우가 있다. 그럴 수도 있다고 생각한다. 하지만 비판적이며 창의적인 프로세스, 해결책에 도달한 방식, 팀에서 자신에게 중요한 것이 무엇인지 알아내야 한다”
  3. 회사의 사명을 이해하지 못함 : Doesn’t understand the company’s mission
    • 컴피테라(Competera)의 CTO 유진 네이데노브
    • “지원자가 우리의 제품, 시장 영역, 실제 세계에서 이것이 해결하는 문제에 대해 신경을 쓰지 않고 순수하게 기술 지향적인 사람이라면 적색 신호라고 생각한다. 실질적인 비즈니스 사례를 해결하고 최종 사용자에게 최대한 실질적인 가치를 제공할 수 있어야 한다”
    • 제니 랜섬: “양쪽 모두에 어느 정도 주의를 기울여야 한다.”
    • “만약 후보자가 그들의 연구를 짧게라도 하지 않았다면, 그것은 단지 어느기업이 그들에게 가장 많은 돈을 지불할 수 있는지만 보고 지원한 것이다. 회사가 무엇을 하고, 지원자가 무엇을 만들 수 있는지에 대한 요소가 결정을 내리는 요소로 작용하지 못할 경우, 향후 채용 결정이나 유지 문제로 이어질 수 있다.”
  4. 기술에 관해서만 이야기함 : Only talks tech
    • FRG(Frank Recruitment Group)의 CEO 제임스 로이드 타운쉔드
    • “두문자어를 술술 이야기하고 장황한 기술 용어로 답할 수 있는 지원자는 기술에 능한 면접관을 안심시킬 수 있다. 하지만 그렇다고 항상 기술 또는 기술 지식을 활용해 비즈니스 문제를 해결할 수 있는 방법을 이해하는 것은 아니다”
    • 질문을 할때 전문용어를 사용하는 것을 피하고, 지원자가 암기한 답변을 하는 것처럼 보이는 경우 추가적인 설명을 요청하라고 조언
    • “그들이 그렇게 할 수 없는 경우 그들이 형편없는 의사소통자 이거나 최악의 경우 해당 기술 또는 프로세스를 완전히 이해하지 못하고 있다는 뜻일 수 있다”
  5. 믿기 어려운 스킬 목록 : Implausible skills list
    • OSP 인터내셔널(OSP International)의 CEO 코넬리우스 피시트너
    • “특히, IT에서는 그렇다. 자신의 스킬을 과장하는 지원자들이 아주 흔하다”
    • 지원자에게 과제를 할당하되 제출 시한을 설정하고 비용을 지불하라고 조언.
    • “우리는 그들이 최선을 다하도록 동기를 부여하고 최고의 인재를 놓치지 않기 위해 비용을 지불한다. 또한 그들은 과제를 더욱 진지하게 받아들인다. 이 방식으로 업무를 완수할 사람과 시간과 돈을 낭비할 사람을 구분할 수 있다. IT에서는 말보다 행동이 우선이기 때문에 우리는 지원자가 후보자가 할 수 있다고 한 일을 할 수 있는지 알아야 한다”
  6. 그저 일자리만 구하려는 태도 : Not career-minded
    • IH(Intermountain Healthcare)의 CIO 크레이그 리차드빌
    • “지원자 스스로 조직의 ‘사명’과 ’목표’에 기여할 계획을 가지고 있어야 한다. ’학습’, ‘성장’, ‘개발’, ‘지속적인 기여’ 욕구가 있어야 한다. 그들이 비즈니스에 어떻게 영향을 미치려는지에 대한 계획에 대한 생각이 없고, 커리어 발전에 대한 계획에 대한 생각이 없을 수록, 잘 맞을 가능성이 낮다”
    • 베츠(Betts)의 수석 채용 담당자 멜리사 허쉬
    • 지원자가 사려 깊게 조사하지 않은 것 같은 느낌일 때 적색 신호가 나타난다고 말했다.
    • “그들은 수십 개의 회사에 지원한다. 면접관은 항상 지원자가 정말로 그 직업을 원하고 조사를 했는지, 마지못해 하는지 그리 어렵지 않게 알 수 있다”
  7. 구체적으로 설명할 수 없음 : Can’t get specific
    • 캘리포니아대학교 얼바인 캠퍼스의 CDO 겸 정보, 기술, 데이터 부총장 톰 안드리올라
    • 원자에게 직무 관련 경험에 대한 설명을 요청한다. 구직자가 구체적으로 설명할 수 없을 때 경고 조짐을 감지
    • “변화와 전환을 추진하는 주요 역할의 경우, 조직이 헤쳐 나아가도록 도운 경험과 이에 수반되었던 문제를 명확히 표현할 수 있는 사람들이 있다. 나는 그것의 깊이를 테스트하고 싶다”
    • 베츠의 허쉬
    • 세부사항의 부재가 문제 신호일 수 있다는 점에 동의
    • “대화 당시에 회사와 구체적으로 관련되지 않았으며 다른 기업의 다른 면접에서 반복될 수 있는 질문에 답하는 경우 조심해야 할 수 있다”
    • 컨설팅 기업 DT(DifferentThinking)의 설립자 겸 CEO 지비트 인바
    • 지원자에게 문제를 해결한 방식의 예를 묻고 ’그들이 직면했지만 잘 해결되지 않았던 문제에 관해 질문’하는 경우가 많다. 인바는 “일부 지원자는 올바르게 해결하지 못했던 문제를 기억하지 못한다. 하지만 우리 모두는 문제에 직면하고 실수를 범한다. 이를 인정하지 않는 것이 적색 신호이다”
  8. 원격면접 시 카메라 비활성화 : No picture
    • 허쉬
    • 원격 면접에서 비디오 없이 회의에 참석하는 것은 자신감의 부족, 또는 의지의 결여를 의미
  9. 독불장군 : Goes it alone
    • 세이프티컬처(SafetyCulture)의 CTO 제임스 심슨
    • 지원자가 이전 직장에서 동료의 기여도를 인정하지 않을 때 우려
    • “그들이 자신의 기여도 측면에서만 직업 생활 업적을 설명하고 참여했을 수 있는 팀에 대한 언급을 누락하는 경우 다시 한번 생각하게 된다”
    • 지원자가 업무상 내려야 했던 어려운 결정이 무엇이었는지에 대해 질문하는 경우가 많다. 그는 기술보다는 동료에 대한 초점을 살펴본다.
    • “나는 코칭, 주도, 성과 관리 등 사람과 관련된 이야기를 듣고 싶다. 사람들은 업무에 있어서 가장 복잡하지만 중요한 부분이다. 하지만 때로는 지원자가 그들이 내린 기술 결정에 관해 이야기한다. 그 부분도 관심이 있지만 이를 통해 그들의 초점이 드러난다”
    • “나는 또한 누군가 범했던 가장 중대했던 실수와 그들이 배운 교훈에 관해 질문한다. 그들이 경험으로부터 교훈을 얻을 수 있다면 좋은 것이다. 나는 그것을 원한다. 하지만 경우에 따라 자신의 잘못이 아니었던 이유, 또는 다른 사람이 문제였던 사연만 풀어놓는 이들이 있다”
  10. 채용 프로세스 중 태도의 변화 : Shifting expectations from first interview to final
    • GA(General Assembly)의 인재 및 다양성, 평등, 포용 부사장 티파니 어빙
    • 초기 면접과 최종 면접 단계 사이의 차이가 보이는 경우가 증가
    • “근무 시간 및 보상 측면에서 다른 기업의 제안 때문인 경우가 많다. 고용팀은 역할에 적합한 사람을 찾았다고 기뻐하다가 나중에 고용에 실패한다. IT 전문가에 대한 수요가 지속적으로 증가함에 이런 일이 더욱 자주 발생하고 있다”
    • 이런 우려에도 불구하고 원칙을 유지하는 것이 중요하다고 말했다. 엄격한 면접과 조사 프로세스를 유지하지 않으면 나중에 대가를 치를 수 있다.
    • “기술 인재를 고용할 때 시간적 제약이 따르는 경우 더 신속히 처리하기 위해 수정하는 경우가 있다. 그러나 편법은 잘못된 고용의 지름길이다. 나중에 자신이 결국 책임지게 될 수도 있다”

Reference

  1. “급하다고 질러가지 마라” IT 채용 시 유의해야 할 10가지 조짐 - CIO Korea, 2022-08-17
  2. 10 red flags to watch for when hiring, 2022-08-15

[컴][swe] 전임자의 나쁜 코드를 대하는 태도

 

나쁜 코드 욕나오는 코드 대하는 훌륭한 방법/ 개똥 / crap code / 이전 코드 / 나쁜 코드 수정할 때

전임자의 나쁜 코드를 대하는 태도

ref. 1 에서 제시하는 방법

  1. 불평하지 마라, 누구도 듣고 싶어하지 않는다.
  2. 시간이 있을때 수정하자.
  3. 다른이들도 같이 수정하게 하자.
  4. 모두를 위한 모범예제를 하나 만들자.
  5. 수정하기전에 test code 를 추가하자.
  6. 수정을 위해 단기, 장기계획 모두를 세우자.
  7. 빠르게 수정하고, 이슈가 생기면 다시 돌아가서 수정하면 된다.

from: ref. 1 의 마지막 문단(Endnote)

성급하게 고치지 마라, 당신이 이해하지 못하는 이유가 있을 수 있다. 그런 코드외에도 개똥같은 코드들은 있다. 불평하지 마라, 누구도 듣고 싶어하지 않는다. 자신들이 일을 어지럽혔다는 소릴 듣고 싶어하지 않는다. 당신도 그런말을 들으면 싫어할 것이다.

항상 방문하고 나서 떠날때 자리를 치우고 가자. 깨진 창문을 수리하자. 시간이 있을때, 다른 이들도 그것들을 수리하도록 해라.

버그를 수정하기 전에 test 를 추가해라 시간이 지나면, 수정 또는 refactoring 을 한 것에 대해 더 자신감을 갖게 될 것이다. 모두를 위한 예제를 만들어라, 하나씩 이 예제를 통해 모두가 조금씩 기여하고, 코드베이스를 더 나은 곳으로 만들 수 있다. 하룻밤사이에 만들어지지 않지만, 시간이 지나면, 누구도 인식하지 못할 것이다.(me: 아마도 지난 코드를)

만약 그것이 정말 끔찍하다면, 그것이 무엇인지, 왜 그것이 끔찍하다고 생각하는지 지적해라. 그것을 고치거나 고치지 않는 것이 어떻게 그것이 비지니스를 반영할것인가? 당신이 향상시킬 수 있는 것에 대한 짧은 계획, 긴 계획을 만들어라. 그러면, 당신은 항상 가치를 가져올 것이다.

그리고 기억해라, 다음 싸움은 언제든 일어날 수 있지만, 불이 끝난 이후에 다시 돌아와서 그것을 수정할 필요가 있다는 것이 잘 전달됐다면, 지름길을 가는 것을 두려워 하지 마라.

결국 당신은 휴일에 추가 케이크를 먹는 것으로 체중이 더 늘지 않을 테지만, 매일 추가적인 케잌을 먹으면 그럴 수 있다.

개인적인 생각

코드를 수정하면서 욕이 나오면, 고치면서 욕을 해라, 그것이 정신건강에 좋다. 다만, 혼자있을 때 하자. 남들이 들으라고 욕을 하지 말자.

그러나 더 나은 코드로 수정도 하지 않고, 그 코드를 욕만 하는 것은 대안없이 욕을 하는 듯 보인다.

See Also

  1. “Who wrote this s**t, asked the CTO. Flustered, he checked git blame, and the answer was him” : programming : 어떻게 코딩을 해야 하는지에 대한 답글들이 재밌다.

Reference

  1. Who wrote this shitty code? | OverfittedCat | Medium, 2022-01-20

[컴][swe]개발자 번아웃을 하게 하는 요소

burnout / burn out / developer / 리서치 조사 /

개발자 번아웃을 하게 하는 요소

  • 기관 : 세일즈포스 산하의 앱 통합 기업 ’뮬소프트(MuleSoft)’가 ’밴스 본(Vanson Bourne)’과 함께 시행
  • 설문조사 대상 : 600명에 달하는 CIO와 IT 의사 결정권자
  1. 증가하는 다른팀으로부터의 일/요구, 15%
  2. 디지털 전환 압박, 13%
  3. 기술 부족, 13%
  4. 주요 우선순위 밖의 증가하는 매일의 문제를 처리하는 것, 13%
  5. 빠르고 충분한 새로운 고용의 어려움, 10%
  6. 자동화할 수 있는 반복적인 일, 10%
  7. 적용할 새로운 technologies 과 새루운 접근법에 대한 새 skill들을 익히는것, 9%
  8. 혁신에 투자하기에 충분하지 않은 시간, 9%
  9. tooling 과 느린 개발 사이에 제한된 상호연동성(interoperability)
  10. 내가 아는 이유가 없다, 2%
  11. 기타 0%

개발자가 감당해야 하는 여러 가지 형태의 ’부담을 덜어주는 것’이 문제 해결을 위한 첫걸음이라는 것

References

  1. “채용난 이유 있다, 개발자 번아웃 주요 요인은…” 뮬소프트 조사 - CIO Korea, 2022-04-20
  2. New Research Shows How to Keep Developers Happy Amid the ‘Great Resignation’ - Salesforce News

[컴][swe] Jmeter

테스트툴

Jmeter

환경

  • windows 10

download

run in gui mode

<jmeter-home>/bin/jmeter.bat 를 실행하면 된다.

GUI mode 는 script 만들때 사용, load test 를 할 때는 CLI 모드를 사용 [ref. 1]

setenv.bat<jmeter-home>/bin 에 존재하면 setenv.bat를 실행해 준다. 다음처럼 setenv.bat를 생성했다. 이외에도 필요한 환경변수는 setenv.bat에 넣으면 된다.

rem setenv.bat
set JAVA_HOME=d:\a\apps\java\openjdk-jdk-15.0.1
set PATH=%PATH%;%JAVA_HOME%\bin

rem jmeter 실행시에 쓰이는 변수를 override 할 수 있다.
set JVM_ARGS=-Xms1024m -Xmx1024m -Dpropname=value

test 생성

  • ref. 2 의 Thread Group 참고
  • ’Test Plan’에서 원하는 element 를 추가할 수 있는데, ’template’은 이 element 를 어느정도 set 해놓은 상황이다.

Test Plan Element 들

  • jMeter - Test Plan Elements

  • JMeter Test Plan 은 test element 들로 구성된다.

  • 적어도 하나의 Thread Group 으로 구성된다.

  • 각 Thread Group 에서, 하나 이상의 다른 element 들의 조합을 놓을 것이다.(Sampler, Logic Controller, Configuration Element, Listener, and Timer)

  • Pre-processor element --> Sampler --> Post-Processor element + Assertion element 순서로 실행된다.

Thread Group

  • sample error 가 발생한 후 thread 를 stop 할지, test 를 stop 할지, 계속진행할지에 대한 판단 가능
  • thread 개수 : user수, 즉 연결수를 simulate 하는 것으로 보면 된다.
  • 확장 시간(ramp-up time) : JMeter 가 모든 thread들을 running 하게 만들기 위해 최소 얼마나 시간이 걸리게 할 것인지. 이 값이 크면 천천히 전체 thread 개수를 running 을 하는 것이 천천히 이뤄진다?
  • Loop count : 테스트를 실행하는 회수
  • 스케쥴러 설정 : test 를 실행하는 시간, 끝나는 시간을 설정할 수 있다.

Contorllers

다음 2가지가 있다.

  • Samplers
  • Logic Controllers

Samplers

  • sample 을 만드는 녀석이라고 보면 된다.
  • 특정 type 의 request 를 서버에게 보내게 해준다.
  • page 를 위한 user request 를 시뮬레이한다. 예를 들어 HTTP service 의 POST, GET, DELETE 등을 수행할 때는 HTTP Request sampler 를 추가할 수 있다.
  • HTTP, FTP, JDBC, Java, SOAP/XML, RPC request 들에 대한 sampler 가 있다.

Logic Controllers

request 를 반복시키거나, 특정 조건에서 돌게 하거나 등의 처리를 할 수 있다.

  • Logic Controllers는 Thread 에서 Samplers 의 처리 순서를 제어할 수 있게 해준다.
  • Logic Controllers는 child elements 에서 오는 request 의 순서를 변경할 수 있다.
  • controller 들
    • Simple Controller
    • Loop Controller
    • Once Only Controller
    • Interleave Controller
    • Random Controller
    • Random Order Controller
    • Throughput Controller
    • Runtime Controller
    • If Controller
    • While Controller
    • Switch Controller
    • ForEach Controller
    • Module Controller
    • Include Controller
    • Transaction Controller
    • Recording Controller

Test Framgments

  • Test Fragments 는 Module Contorller 또는 Include_Controller 에 의해 referenced 되지 않으면 수행되지 않는다라는 점에서 Thread Group 과는 다르다
  • 이 element 는 Test Plans 내에서 오직 code 재사용을 위해 쓰인다

Listeners

  • Listener들은 Sampler들의 결과를 보여준다. tables , 그래프, 트리, log file 의 간단한 test 등의 형태로.
  • JMeter의 Sampler component 가 수행될때, JMeter 에 의해 모아진 test case에 대한 데이터에 대한 접근 비쥬얼적인 접근을 제공한다.
  • test 의 어느곳에나 추가될 수 있다.
  • 그들의 level 이하의 elemnt 들에게서 나오는 data만을 모은다.
  • JMeter 가 제공하는 모든 Listener들
    • Sample Result Save Configuration
    • Graph Full Results
    • Graph Results
    • Spline Visualizer
    • Assertion Results
    • View Results Tree
    • Aggregate Report
    • View Results in Table
    • Simple Data Writer
    • Monitor Results
    • Distribution Graph (alpha)
    • Aggregate Graph
    • Mailer Visualizer
    • BeanShell Listener
    • Summary Report

그외

  • Timers
  • Assertions
  • Configuration Elements : Sampler 에서 사용되는 변수를 만들게 해준다.
  • Pre-processor Elements
  • Post-processor Elements
  • Execution Order of Test Elements

Best Practices

JMeter는 특히 분산 환경에서 실행되는 경우 몇 가지 제한이 있다. 이 가이드는 실제적이고 연속적인 부하(load)를 생성하는 데 도움이 된다.

  • 스레드 수가 많을 경우 JMeter를 여러개 실행해서 사용
  • Scoping Rules 를 체크하고 그에 따라 design
  • 모든 elements에 항상 naming convetion을 사용
  • 스크립트를 실행하기 전에 기본 브라우저의 연결 설정(Connectivity Settings)을 확인
  • Listeners를 적절하게 추가.
  • 다음은 리소스 요구사항을 줄이기 위한 방법
    • non-GUI 모드(jmeter -n -t test.jmx -l test.jtl) 사용
    • Listener를 최대한 적게 사용. 위와 같이 -l 플래그를 사용하는 경우 Listener를 모두 삭제하거나 비활성화할 수 있다.
    • “View Result Tree” Listener는 메모리를 많이 소모한다. 콘솔이 중지되거나 JMeter의 메모리가 부족해질 수 있으므로 사용하지 않도록 설정한다. 그러나 “Errors”만 선택한 상태에서 “View Result Tree” Listener를 사용하는 것은 괜찮다.
    • 유사한 Sampler를 많이 사용하는 대신 loop에서 same sampler와 변수(CSV 데이터 세트)를 사용하여 sample을 다양하게 변경하자. 또는 Access Log Sampler 를 사용하자.
    • functional mode를 사용하지 마십시오.
    • XML 대신 CSV 출력을 사용.
    • 필요한 데이터만 저장.
    • 가능한 한 적은 수의 Assertions를 사용.
    • 모든 JMeter 그래프는 메모리를 많이 사용하므로 사용하지 않도록 설정. 웹 인터페이스의 JTL 탭을 사용하여 모든 실시간 그래프를 볼 수 있다.
    • CSV Data Set Config(CSV 데이터 세트 구성)에서 local path를 지우는 것을 잊지 마라.
    • 모든 테스트 실행 전에 Files tab을 비우자

Reference

  1. Apache JMeter - User’s Manual: Getting Started
  2. jMeter - Quick Guide
  3. jMeter - Best Practices

[컴][swe] 실력있는 프로그래머가 필요한 이유

테스트가 필요한 이유/ 시니어(senior)의 이유 / cs 를 잘알아야 하는 이유/ computer science

실력있는 프로그래머가 필요한 이유

  • Boeing’s 737 Max Software Outsourced to $9-an-Hour Engineers - Bloomberg
    • Max 의 소프트웨어는 보잉이 비용절감을 위해 경험이 많은 엔지니어들을 해고하고, 공급자들을 압박하는 시점에 개발됐다.

      The Max software -- plagued by issues that could keep the planes grounded months longer after U.S. regulators this week revealed a new flaw -- was developed at a time Boeing was laying off experienced engineers and pressing suppliers to cut costs.

    • 전 보잉 소프트웨어 엔지니어 Rabin : 이전의 한 매니저가 보잉의 상품이 안정돼서(mature) 이제 보잉은 시니어 엔지니어가 필요없다고 했다.

      Rabin, the former software engineer, recalled one manager saying at an all-hands meeting that Boeing didn’t need senior engineers because its products were mature. “I was shocked that in a room full of a couple hundred mostly senior engineers we were being told that we weren’t needed,” said Rabin, who was laid off in 2015.

  • “1억 줬다가 9,990만 원 반납하라” 황당 행정 ‘분통’ : https://www.youtube.com/watch?v=tzAFVpIfCCw&t=1049s
    • 해당 자영업자들의 세금자료를 불러와서 보상금을 계산하도록 프로그래밍을 했다.
    • 프로그램을 잘못만들어서 발생 : 영업이익 셀을 불러와야 하는데 다른 셀을 불러와서 잘못된 금액이 지원금으로 나갔다.

See Also

  1. 쿠…sal: [컴] Unit test best practices in C#

[컴][swe] 개발에 의해 생기는 복잡성 관련 이야기

개발 / 엔지니어링 / 무엇을 개발하고 무엇을 갖다 써야 할까

ref. 1,2 의 이야기를 그저 모아놓았다. 이야기의 결론은 개발자들이 자신들이 직접개발 또는 운영할 것과 그저 사용할 것들을 구분하는 능력이 필요하다. 그리고 조직이 커질수록 좀 더 통일된 툴들, 방법들을 사용해야 한다. 고 정리할 수 있을 듯 하다.

많이 알려져 있는 이야기라 새롭지는 않지만, 이 기사에서 인용한 거대 IT기업의 관련자들이 언급한 말들이 좋은 참고자료가 될 것이라 생각한다.

개발에 의해 생기는 복잡성 관련 이야기

월트 디즈니의 기업 기술 전략 총괄이었으며 현재 컨설턴트인 ‘나이젤 심슨’

  • “개발자들이 애플리케이션 개발과 머신러닝을 위한 고차원적 프레임워크를 이용해 더욱 많은 일을 할 수 있게 되었지만, 반대급부가 나타났다. 선택지의 폭발과 개발 속도의 가속화는 개발자가 시대정신을 따라가는 것을 어렵게 만든다. 그러면서 수많은 개발자가 headlight 에 빠진다.”

“It has never been more difficult to be a software developer than it is today,” said Nigel Simpson, a consultant and former director of enterprise technology strategy at Walt Disney. “While we’ve seen an up-leveling of capabilities that enable developers to do more by using high-level frameworks for application development and machine learning, this comes at a cost. The explosion of choice and the pace of development make it challenging for developers to keep up with the zeitgeist, with many developers getting caught in the headlights.”

Essential and accidental complexity

소프트웨어 에이전시인 심플 스레드(Simple Thread)의 공동 설립자인 저스틴 에더리지

  • 기본적 및 우발적 복잡성(essential and accidental complexity)을 구분.
  • “기본적 복잡성은 사업 영역 안에 있다. 기업의 환경은 극도로 복합적이고 따라서 기업이 해결하려고 하는 문제는 본질적으로 복합적일 수밖에 업다. 그리고 우발적 복잡성이 있다. 이는 우리의 여러 도구와 관련이 있다. 또 우리가 문제를 해결함에 있어 다루는 계층과도 관련이 있다”

클라우드 네이티브 시대는 우발적 복잡성의 가능성이 어느 때보다도 더 높다. 개발자는 이용할 수 있는 툴킷을 최대한 활용하려 하고, 개발자의 상사는 개발자가 고객에게 가치를 전하는 데 전념하기를 원하면서, 서로 충돌한다.

에더리지는 “오늘날의 소프트웨어 개발자 부족 현상을 감안하면, 개발자가 우선적으로 고객에게 가치를 전달하도록 압박할 여지가 별로 없다”면서 “엔지니어가 이런 식으로 생각하도록 만드는 일은 쉽지 않다”라고 말했다.

풍부한 선택의 나쁜점

소규모 독립적 팀이 고객 요구에 대응해 서비스를 제작하려는 움직임

금융서비스업체 투시그마의 플랫폼 엔지니어링 책임자인 카밀 푸르니에(Camille Fournier)

  • 인포월드와의 인터뷰에서 “당신은 클라우드 내 사탕가게에 있는 아이와 같다”고 말했다. “하지만 여러분이 성장하고 잘 맞게하려고 노력할 수록, 그 복잡성은 절대적으로 배가됩니다.”
    > “But as you grow and try to make things fit together, the complexity absolutely multiplies.”

평균적인 소프트웨어 개발자에게 이러한 선택 수준이 과연 긍정적인가

레드몽크(RedMonk)의 애널리스트인 스티븐 오’그래디

  • 2020년 블로그 게시물
  • “수많은 서비스를 이용할 수 있다는 사실에 내재된 복잡성은, 특정한 환경에서, 강점이라기 보다는 오히려 부담으로 작용할 수 있다.”

내부 플랫폼 구축(internal platform)

  • 증가 중인 복잡성 문제는 여러 조직이 중앙 플랫폼 모델을 도입하도록 유도
  • 내부 플랫폼 팀이 엔지니어에게 필요한 툴을 검토하고 템플릿을 제작하고 이들이 실무에 쉽게 유입될 수 있는 골든 패스(golden paths)를 계획하는 일을 담당
  • 재무 업무, 보안, 거버넌스 등의 기능을 중앙화해 개발자의 부담을 완화

휴머니텍의 ‘본 그런버그’

  • 휴머니텍(Humanitec)의 설립자인 카스파 ‘본 그런버그’
  • 휴머니텍은 기업이 자체 개발자 플랫폼을 제작하는 데 도움을 주는 신생 기업
  • 우수한 내부 개발자 플랫폼의 핵심
    • Dark Side of Self-Service | Humanitec
    • “개발자가 당면한 일을 진척시키기 위한 셀프 서비스, 그리고 가치가 적은 작업을 제거하는 것 사이의 균형을 발견하는 것이고, 이때 개발자가 제약이 있다는 느낌을 받지 않아야 한다”

스포티파이 제품 매니저인 ‘니먼’

  • How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem : Spotify Engineering
  • “6년 정도 전부터 스포티파이는 자율적 팀을 바탕으로 애자일 엔지니어링 문화에 전념했다”면서 “온갖 장점이 있었지만, 복잡성도 발생했다. 예를 들어 개발자 툴링 생태계의 파편화이다. 여기서는 무언가를 하는 방법을 알려면 동료에게 물어보는 수밖에 없었다”라고 말했다.
  • 물론 이 방식은 스포티파이의 급속한 성장을 이끌었다. 그러나 이제는 오히려 혁신 속도를 늦추고 있음이 드러났다. 통합과 단순화가 필요했다. 니먼은 “권고된 툴링은 쉽게 발견할 수 있어야 한다. 전체 툴링의 여정은 명확해야 한다. 양질의 이용자 설명서가 있어야 한다. 그리고 일을 하다 막혔을 때 지원받을 곳이 분명해야 한다”라고 말했다.
  • “골든 패스(golden path)의 배경이 되는 생각은 엔지니어를 제한하거나 억압하지 않는 것이고, 또는 이를 위해 표준을 정립하지 않는 것이다. 골든 패스가 정착하면 팀은 바퀴를 재발명 할 필요가 없고, 내려야 할 결정의 수가 줄고, 자신의 생산성과 창의성을 고차원적 목적을 위해 사용할 수 있다. 이들은 신속한 움직임으로 돌아갈 수 있다”

‘나이젤 심슨’

  • “개발자가 툴을 재발명하고 싶어하는 것”이 문제라면서 “더 나은 쥐덫을 만드는 것만큼 개인적으로 만족스러운 일도 드물다”라고 말했다.

마이크로소프트의 개발자 사업부의 제품 CVP인 ‘아만다 실버’

  • “개발자를 억압하려 하는 조직이 있는가 하면 개발자에게 재량권을 주려는 조직이 있게 마련이다. 핵심은 개발자 속도라는 개념이다. 개발자가 자신이 코딩할 수 있는 것만 코딩하고, 전문성이 없는 영역을 배워야 하는 부담을 지거나 산만해지지 않는 체계를 구축하는 것이 좋다”라고 말했다.

아마데우스 인프라 및 클라우드 책임자인 에도드 허빈

  • 1987년에 설립된 여행 기술 회사인 아마데우스(Amadeus)
  • “개발자들이 회사가 제공하는 핵심 위에서 개발할 수 있어야 한다. 따라서 플랫폼을 사용한 방법으로 이들에게 기능을 제공한다”
  • “신기술은 보안과 안정성 때문에 보다 많은 복잡성을 가져온다. 이런 시스템을 가동하는 데는 안정성이 중요하다. 데이터 주도형 애플리케이션의 출현은 우리에게 차원이 다른 복잡성이다. 이는 애플리케이션을 코딩하고 피드백 루프를 구축하는 새로운 방식이다. 이들은 모두 새로운 것이고 복잡성을 가져온다”
  • 내부 팀이 솔루션을 설계하거나, 합당한 경우 매니지드 서비스를 이용하며 복잡성을 완화하려 한다.
  • 데이터베이스가 한 사례다. 아마데우스는 몽고DB 인스턴스를 자체적으로 운영했지만, 이제 벤더가 관리하는 몽고DB 아틀라스를 이용한다. 회사는 관리형 쿠버네티스에도 비슷한 관점을 취하고 있다.
  • 허빈은 “간혹 거부해야 할 때가 있다”면서 “최근 사람들이 새 데이터베이스를 도입하려고 했다. 이들의 생각은 타당했다. 그러나 선택지가 아주 우수한 것이 아니라면 회사가 사용하는 데이터베이스의 수를 통제하는 것이 더 좋다”라고 말했다.

투 시그마(Two Sigma)의 ‘포니어’(Fournier)

  • 대형 조직에는 다양한 유형의 엔지니어가 있다. ‘탄력적 시스템을 구축하는 일에 전념하는 엔지니어’, ‘고객에게 신속히 기능을 전달하는 데 전념하는 엔지니어’가 있는가 하면, ’꼭 최신 기술을 쓰려는 애쓰는 엔지니어’(who desperately want to tinker with the latest technology)도 있다. 두 유형 모두 가치가 있지만 이들을 주의 깊게 관리해야 한다
  • “새로운것의 내부를 살피고, 이해하는 것을 좋아하는 사람을 원할 것이다.(왜냐하면 베어메탈(bare-metal) 쿠버네티스를 운영할 사람이 있어야 하기 때문이다.) 한편 새로운 것을 살펴보면서 작용 방식을 이해하고, 회사의 어떤 부분에 이것이 유용한지를 판단하고, (프로토타입을 같이하기 좋은 파트너들과 ) 투자할 가치가 있는지를 판단하는 것을 좋아하는 사람도 필요할 것이다.”

어떻게 vendor들이 복잡성과 싸우고 있는지

구글 클라우드의 수석 디벨로퍼 애드보킷인 켈시 하이타워

  • 현재 개발자에게 주어진 선택의 풍부함이 ‘선물이자 저주’라고 생각.
  • 선물: 거의 무제한적인 수의 기술을 개발에 사용할 수 있다
  • 저주: 개발자가 개발자의 워크플로우까지 인프라가 흘러나오는 상황에 빠지고 있다.
    deveopers “are being pulled into situations where we leak the infrastructure up into their workflow”

레드몽크(RedMonk)의 애널리스트인 스티븐 오’그래디(O’Grady )

  • The Developer Experience Gap – tecosystems
    • “물론, 필수적인 조각을 모두 제공할 수 있는 벤더는 없고, 앞으로도 그럴 것이다. 심지어 가장 다양한 애플리케이션 포트폴리오를 보유하고 있고 역사적으로 전례가 없는 배포 속도를 가진 AWS조차 모든 개발자 니즈를 충족시킬 수 없고, 모든 연관 개발자 커뮤니티를 소유할 수 없다”
  • Addition By Abstraction – tecosystems
    • “우리는 구매자와 개발자를 모두 미로 안으로 보내는 일로부터 탈피하고 있음을 시사하는 증거가 풍부하다. 우리는 이들이 원시적인 것을 선택해 처음부터 조립하도록 하는 작업으로 부담을 주었다. 최초의 클라우드 시대를 원시적인 것으로 정의한다면 이는 끝나가고 있다. 컴퓨팅 산업이 처음부터 그랬던 것처럼, 후속의 클라우드 시대는 우리가 이들 원시적인 것 위에 구축하는 추상화로 정의될 것이다.”

While assembling these primitives into coherent internal platforms has already proved something of a successful workaround for many engineering-led organizations, more traditional enterprises are absolutely going to look to their providers to help them ease this complexity.

기술에 대한 이해는 필요

개발자들이 사용하는 기술들이 추상화돼서 손쉽게 사용할 수 있다고 해도, 그 기술에 대한 이해는 필요하다.

As the legendary British racing driver Jackie Stewart has said, “You don’t have to be an engineer to be a racing driver, but you do have to have mechanical sympathy.” Or, to be truly great, you have to hav

마이크로소프트의 ‘아만다 실버’

  • “개발자는 시스템 사람들이다. 우리는 우리가 개발하고 있는 환경 시스템이 어떻게 작용하는지에 대해 구조를 이해하고 작은단위 하나하나까지 이해하고 싶어한다. 그러나 동시에 깊이 파고들기를 원하지 않는 모든 종류의 영역이 있다”라고 말했다.

    “Developers are systems people. We like to understand how the system works all the way down to the bare metal and the architecture we are building on. But at the same time, there are all kinds of domains where you don’t necessarily want to get that deep into it,”

여러 개발자 및 그의 팀이 해야 할 일

어디가 자신의 전문성이 가장 가치 있는 분야 이고, 어디가 ’바퀴를 재발명’하면서 낭비되고 있는지를 식별하는 것이다.

The task for many developers and their teams is to identify where their expertise is most valuable and where it is being wasted reinventing the wheel.

소프트웨어 개발자가 이용할 수 있는 선택과 복잡성이 오늘날보다 더 풍부한 적은 없었다. 동시에 추상화의 선택지 또한 이렇게 많은 적이 없었다. 결국 문제는 개발자와 개발자의 조직이 목표를 추구해가면서 어느 정도까지 복잡성을 소화할 수 있는가로 귀결된다.

There has never been more complexity and choice available to software developers than there is today, but there have also have never been more options to abstract it away. It just comes down to how much complexity you and your organization can stomach in the pursuit of your goals.

Reference

  1. 복잡성이 SW 개발자를 죽인다··· ‘패러다임의 전환’ 올까? - CIO Korea
  2. Complexity is killing software developers | InfoWorld

[컴][swe] 팀(team)에 안좋은 태도

https://www.ciokorea.com/news/202104?page=0,1

리더 / 리더가 주의해야 할 팀 자세 /

팀(team)에 안좋은 태도

  1. 무례함
    • 카네기 멜론 대학교 테퍼 경영 대학원의 박사 후 연구원인 빈야민 쿠퍼는 “무례함은 경시하고 인격을 훼손하는 언사, 모욕, 눈 굴리기, 남의 성취를 가로채기, 또는 조직의 유대감으로부터 누군가를 소외시키는 등의 행동이다”라고 설명
  2. 방관
    • 클라우드 보안 및 컴플라이언스 서비스 사업자인 퀄리스(Qualys)의 CTSO인 폴 베어드는 “리더는 개인을 이해하고 팀이 전체적으로 어떻게 기능하는 지를 파악해야 한다”면서 “이들의 의욕을 고취하는 것이 무엇인지, 팀에 어떤 일이 일어나고 있는지를 이해한다면 문제가 유해한 부정성으로 변질되기 전에 이를 포착할 수 있다”
  3. 비관주의, 냉소주의
    • 약간의 체념은 건전할 수 있다. 왜냐하면 팀이 최악의 시나리오를 고려하는 데 도움이 되기 때문이다.
    • 벤-요세프는 “그러나 이게 팀의 제반 상호작용에서 기본적인 양태가 되어서는 곤란하다”라고 경고했다. (아비브 벤-요세프 컨설팅(Aviv Ben-Yosef Concultiing)의 기술 임원 컨설턴트이자 코치인 아비브 벤-요세프)
  4. 질투
    • 온라인 일자리 검색 및 구인 플랫폼 사업자인 베이트닷컴(Bayt.com)의 공동 설립자이자 CTO인 아크람 아사프는 “문제가 악화되기 전에 팀원들이 문제를 솔직히 이야기하고 대처할 수 있도록 장려해야 한다”라고 말했다. 그는 직장 협업의 중요성과 가치를 강조하고 열심히 협업하는 직원에게 보상을 주는 것 역시 유용하다고 지적했다.
  5. 수동적 공격행동
    • 새롭고 갱신된 기능에 대해 동료에게 제안과 질문을 하는 표준적인 절차를 확립하도록 제안한다. 그는 “투명한 절차는 모두에게 소통을 더 쉽게 만들 것이다”면서 “명확한 규칙은 수동적-공격이 발생할 수 있는 수많은 상황을 제거할 것이다”라고 말했다. (by 웹사이트 방문자 분석 기술 사업자인 플러디(Plerdy)의 CEO인 앤드류 초니)
  6. 우월적 태도
    • 리더는 팀워크에 집중하는 제도적 장치를 마련함으로써 잘난체하고 거만한 행동을 최소화할 수 있다. 핸콕은 “중대한 문제에 대해 팀으로부터 의견을 요청한다면 이는 모든 팀원이 가치 있다는 느낌을 갖는 데 도움이 되고 팀으로부터 기대되는 행동 유형의 본보기가 된다”라고 설명. (by 생물공학 연구회사인 마운틴 밸리 MD(Mountain Valley MD)의 CEO이자 사장인 데니스 핸콕)
  7. 극단적 개인주의
    • 인적 자원 소프트웨어 개발자인 넥타(Nectar)의 CEO인 트레버 라슨은 리더는 편애하는 것을 삼가야 한다고 말했다. 그는 “팀 실적이 개인의 실적보다 우선임을 분명히 해야 한다. 그리고 사람들은 분명히 개인적인 직업 목표가 있겠지만 팀의 성공이 무엇보다 중요하다는 점을 강조해야 한다”

See Also

  1. 소프트웨어 팀장(Leader) 가 하지 말아야 하는 행위
  2. 엔지니어링 관리자를 위한 조언

Reference

  1. ‘팀워크를 나락으로…’ IT 리더가 뿌리뽑아야 할 문제 행동 7가지 - CIO Korea, 2021-07-22

[컴][swe] 구글에서 사용하는 개발 방식

google practice / 통일화 / 어떻게 빠르게 / 소프트웨어 엔지니어링 / best practices / 코드리뷰 / 빌드 시스템 / 린팅 linting / lint / build system/ google way / code review / 코드, 소프트웨어 엔지니어링

구글에서 사용하는 방식

소프트웨어 엔니지이렁 at goolge 책 내용 일부

  • What I learned from Software Engineering at Google | Swizec Teller
  • stub, mock 보다 fake 를 사용하자, 이 fake 는 그 담당자 가 만든다.
  • 자주 배포한다. 적은 변화량이 디버깅이나 되돌리기 좋다.
  • 매일, 매시간 등으로 자동으로 배포하도록 구성한다
  • dependency 에 대한 업그레이드 도 마찬가지다.
  • 만약 여럿이 사용하는 코드를 자신의 코드를 변경했다면, 당신이 그 코드와 관련된 코드를 변경해라. 당신이 가장 잘 알며, 당신이 함수를 deprecated 로 만들어서 다른 사람에게 업그레이드를 요청해도 그들은 굳이 하지 않는다.

협업 방식(코딩표준, 빌드시스템, 통신, linting, 코드리뷰)

면책 조항: 저는 공개적으로 알려진 Google 관행을 사용한 경험에 대해 말하는 Google 엔지니어입니다. 나는 나 자신 외에 어떤 것도 대표하지 않는다.

Microsoft와 같은 다른 대기업과 비교하여 Google 엔지니어링 방식에서 가장 극단적인 측면은 회사의 균일성입니다. 몇 개의 프로젝트 외에도 모든 프로젝트의 전체 코드베이스는 동일한 규칙과 프로세스를 가진 하나의 큰 저장소에 있습니다. 이는 엔지니어가 회사에 합류할 때 기여하는 데 시간이 더 오래 걸리지만 초기 단계 이후에는 훨씬 더 빠르게 회사의 모든 제품에 대한 코드를 기여할 수 있음을 의미합니다. 이것은 다른 팀이 만든 구성 요소 간의 통합, 한 팀이 다른 팀과 위기의 시간을 강화하고, 다른 팀이 소유한 코드를 수정하고, 다른 팀이 작성한 코드가 작동하는 방식을 배우고, 팀을 전환하는 데 도움이 됩니다.

이 균일성은 다음과 같은 여러 측면이 있습니다.

  • 코딩 표준: 회사에는 하나의 표준이 있습니다. 언어마다 세부 정보가 있지만 Google에서 Java를 작성하면 작업 중인 프로젝트에 관계없이 동일하게 보일 것입니다. 코딩 표준은 상세하고 합리적입니다(기술 변화에 따라 시간이 지남에 따라 진화합니다). 다른 방식으로 코드를 작성하고 표준이 마음에 들지 않더라도 단일 진실을 갖는 것은 코드 검토 마찰을 줄입니다.

  • 균일한 코드 저장소: 대부분의 Google 코드는 하나의 거대한 가상 저장소에 있습니다. 다른 제품은 단순히 저장소의 디렉토리입니다. repo에 등록할 때 로컬로 복사하지 않습니다. 변경되지 않은 파일은 변경해야 할 때까지 가상으로 액세스됩니다. 빌드 시스템은 빌드 대상도 캐시하므로 코드를 변경하지 않은 경우 제품 바이너리를 다시 빌드하지 않고도 쉽게 사용할 수 있습니다.

  • 균일한 빌드 시스템: Google은 다른 언어에 대해서도 동일한 make 파일과 동일한 빌드 시스템을 사용합니다. 때로는 동일한 make 파일에서도 다른 언어가 지정됩니다. 빌드/실행/테스트를 위한 구문은 제품 전반에 걸쳐 동일하며 인프라 코드의 검사 테스트는 인프라 소비자의 테스트를 자동으로 실행합니다.

  • 균일한 저장 및 통신: 무엇이든 저장하거나 통신해야 하는 경우 유일한 답은 프로토버퍼입니다. 다른 것을 사용하려면 정말 설득력 있는 근거가 필요합니다. 이를 통해 언어, 제품, 팀 및 구성 요소 간에 스토리지, 통신 및 rpc가 원활하게 이루어집니다. Protobufs는 기본적으로 모든 것과 이에 능숙한 모든 엔지니어 간의 인터페이스입니다. Google에서 사용하는 모든 언어에 동일한 protobuf를 빌드할 수 있으므로 언어 ​​간 코드를 쉽게 만들 수 있습니다.

  • Linting: 코드 표준과 빌드 시스템이 균일하기 때문에 Linting에 대한 투자가 증가하면 회사 전체에 이익이 됩니다. 강력한 Linting은 코드 검토 마찰을 더욱 줄여줍니다.

  • 코드 리뷰는 "코드 소유권"(code ownership)과 "언어 능숙함"(language proficiency)(가독성)으로 나뉩니다. 때로는 같은 사람이지만 코드 소유자가 "언어에 가장 능숙한 사람"이지 않은 경우가 많습니다. 이 시나리오에서 한 사람은 제품에 어떤 것이 좋은지 말하고 다른 사람은 일반 코드가 좋은지 말할 것입니다. 이 명확한 구분은 코드 품질과 균일성이 유지되도록 합니다.

소규모 기업은 때때로 유사한 문제(예: 여러 언어 사용 또는 제품 간 통합)를 겪지 않기 때문에 이러한 요소의 대부분은 대기업에 도움이 됩니다. 그러나 그들은 대규모 엔지니어링의 어려운 문제 중 일부에 대한 훌륭한 솔루션입니다.

[컴] 'aws 호주' 의 한팀이 일하는 방식

아마존 개발팀 / 아마존 운영 / 개발방식 / 방법 / 절차 / 시스템

'aws 호주' 의 한팀이 일하는 방식

  • 개발자가 자신이 짠 코드에 대한 테스트코드를 짠다.
  • QA 는 따로 없다.(?)
  • 베타테스트 같은 것들을 하지만, 그래도 production에 버그가 올라갈 수 있다.
  • 이 경우
    • 일단 롤백 하고,
    • Correction of error 를 작성한다.(See Also 1.)
      • 에러가 발생한 이유,
      • 왜 테스트 를 미리 하지 못했는지,
      • 왜 빨리 잡아내지 못했는지,
      • 왜 몰랐는지
    • 이것을 위 director 에게 승인 받고
    • 액션 아이템들을 만든다.
    • 그리고 수정작업을 시작한다.

Correction of error

  • Correction of error 의 목적은 이런 이슈를 걸러내지 못한 프로세스의 개선이다. 문책이 아니다.
  • 액션아이템은 그래서
  • 테스트 시점에서 어떤 식의 테스트가 부족했는지 적는다.
  • 그리고 어떤 식으로 개선한다. 이런 내용을 적는다.
  • 예를들면,
    • 테스트코드에서 어떤 커버리지가 부족하니, 이 부분을 체크해야 한다.
    • 코드리뷰 시점에 코드리뷰 방식에 이점을 보강해야 한다등.

See Also

  1. Correction of Error - AWS Well-Architected Framework

[컴][툴] github 에서 team 만들기

github team / teams / collaborator

github 에서 team 만들기

team 을 만들려면 조직(organization)을 먼저 만들어야 한다.

github 팀(team)의 기능

  • team 안에 또 team 을 생성할 수도 있다. (netsted team)
    • ‘개발팀’ 을 만들고, 그 안에 server team, client team 등을 둘 수 있다.
  • @my-org/team1 을 이용해서 mention 을 할 수 있다.
  • Admin, Write, Read 의 3단계로 repository 에 대한 접근을 제어할 수 있다. 
  • team 에 있는 repository tab 에 가서 repository 를 추가한 이후 좀 더 다양한 권한 관리가 가능하다.
  • discussions 를 사용해서 team 안에서 특정 주제에 대한 토론을 할 수 있다.
  • team 단위로 github project 를 만들어 사용할 수 있다.

github 팀(team) 생성

다음 screenshot 을 보면서 생성하면 된다.




 

old screenshots

team 에 member 또는 repository 추가하기

team 에게 날린 멘션(mention) 찾기

team 에게 멘션 날리기

이슈등에서 글을 적을 때 @/ 을 이용해서 글을 적을 수 있다.

team 에게 날린 멘션 찾기

이렇게 적은 글만을 찾고 싶을 때 “검색” 창에서 아래와 같이 입력해 주면 된다.[ref. 2]

  • team:/

github 전체에서 검색

Code Search 에서도 같은 방법으로 검색하면 된다. 검색에 대한 자세한 사항은 ref. 2 를 참고하자. 그리고 advanced search 를 이용하는 것도 좋은 방법이다.

Bitbucket 과 가격비교

작은 팀(25명 이하)이 여러개의 project 를 진행할 때는 bitbucket 이 낫고, 큰 team 을 위한 작업이라면, github 가 나아 보인다.

bitbucket, team member 수 제한

github 는 team collaboration 을 위한 private repository 를 무료로 제공하지 않는다. 이제는 무료이다.

bitbucket 은 team 관련해서 5명의 멤버까지 무료로 사용가능한 private team repository 를 제공한다.

github, private repository 개수 제한

github 는 private repository 개수를 제한한다. private repository 의 개수제한은 사라졌다.

old screenshots

See Also

  1. https://gitlab.com/
  2. 쿠...sal: [컴][툴] GitHub 협업 - 조직, 팀 만들기
  3. 쿠...sal: [컴][툴] github issue 를 활용하는 방법

Reference

  1. Team Collaboration With GitHub - Tuts+ Code Article
  2. Searching issues - User Documentation

[컴] elasticsearch license

엘라스틱서치 / 일래스틱 / 일라스틱 / 라이센스 /

elasticsearch license

from : Elastic 라이센스, 그리고 오픈 소스 에반젤리스트의 딜레마 - Jongmin’s Lifelog

이 Basic 에 있는 기능은 모두 무료로 사용이 가능합니다. 무료로 배포 되고 깃헙에 코드도 공개되어 있지만 라이센스는 Elastic 사에 귀속되어 있기 때문에 몇 가지는 주의 하셔야 합니다.

Elastic 제품을 내재 한 제품으로 비즈니스를 하려면 Elastic사와 협약을 체결하지 않은 경우 OSS 버전으로만 비즈니스를 해야 합니다. SI, 클라우드 서비스, 컨설팅, 기술지원, 교육 등이 모두 포함됩니다. 그래서 클라우드 서비스 사업자들 중에 Elastic 사와 파트너 협약을 하지 않고 Elastic Stack 서비스를 제공하는 사업자들은 OSS 라이센스에 속한 기능만 서비스를 해야 합니다.

명확하지 않은 부분은 elastic_license@elastic.co 로 문의 하면 된다.

mongo db 의 sspl license

[컴] SchemaSpy 사용

reverse engineering / db schema / how to get db schema / ERD / er diagram

SchemaSpy 사용하기

docker 사용

docker를 사용하면 간단하게 작업할 수 있다. 참고하자.

docker run -v "f:\sspy\:/output" schemaspy/schemaspy:latest -t mariadb -host 172.23.176.1 -port 3306 -db myappdb -u schemaspy -p schemaspypw -dp mariadb-java-client-3.0.8.jar

windows 에서 설치

사용가능한 database

사용가능한 db 의 종류는 아래 command 로 확인할 수 있다.

java -jar schemaSpy_5.0.0.jar -dbhelp

run

여기서는 postgresql 의 database 에 대한 작업을 할 것이다.

postgresql 은 pgsql-t pgsql 을 이용하면 된다. 옵션에 대한 설명은 Commonly used parameters | SchemaSpy 6.0.0 documentation 를 참고하자.

%java% -jar schemaSpy_5.0.0.jar -t pgsql -host <localhost> -db <database_name> -u <user-id> -p <password> -o f:\ -dp postgresql-42.2.20.jar

그리고 난 후 index.html 을 열어보면 된다.

<output_dir>/index.html

최근(2022-11-04)에 mysql 에 대한 작업을 할 때는 제대로 동작하지 않았다. -debug -all 옵션을 넣은경우, error 는 보이지만, 분석된 내용은 만들어졌다.

다음과 같은 error 가 보여졌다.

org.schemaspy.model.InvalidConfigurationException: Schema (-s/-schemas) was not provided and unable to deduce schema, schema is sometimes referred to as user/owner/database

%java% -jar schemaSpy_5.0.0.jar -t pgsql -host <localhost> -db <database_name> -u <user-id> -p <password> -o f:\ -dp postgresql-42.2.20.jar -debug -all

실행모습

D:\a\apps\schemaSpy>d:\a\apps\java\openjdk-jdk-15.0.1\bin\java.exe -jar schemaspy-6.1.0.jar -t pgsql -host localhost:5432 -db mydb -u mytestuser -p mypw -dp postgresql-42.2.20.jar -o f:\schema
  ____       _                          ____
 / ___|  ___| |__   ___ _ __ ___   __ _/ ___| _ __  _   _
 \___ \ / __| '_ \ / _ \ '_ ` _ \ / _` \___ \| '_ \| | | |
  ___) | (__| | | |  __/ | | | | | (_| |___) | |_) | |_| |
 |____/ \___|_| |_|\___|_| |_| |_|\__,_|____/| .__/ \__, |
                                             |_|    |___/

                                              6.1.0

SchemaSpy generates an HTML representation of a database schema's relationships.
SchemaSpy comes with ABSOLUTELY NO WARRANTY.
SchemaSpy is free software and can be redistributed under the conditions of LGPL version 3 or later.
http://www.gnu.org/licenses/

INFO  - Starting Main v6.1.0 on DESKTOP-3TJIL3S with PID 13112 (D:\a\apps\schemaSpy\schemaspy-6.1.0.jar started by namh in D:\a\apps\schemaSpy)
INFO  - The following profiles are active: default
INFO  - Started Main in 0.771 seconds (JVM running for 1.047)
INFO  - Starting schema analysis
INFO  - Connected to PostgreSQL - 13.2
INFO  - Gathering schema details
Gathering schema details...............................................................WARN  - Failed to retrieve stored procedure/function details using sql 'select r.routine_name, case when p.proisagg then 'AGGREGATE' else 'FUNCTION' end as routine_type, case when p.proretset then 'SETOF ' else '' end || case when r.data_type = 'USER-DEFINED' then r.type_udt_name else r.data_type end as dtd_identifier, r.external_language as routine_body, r.routine_definition, r.sql_data_access, r.security_type, r.is_deterministic, d.description as routine_comment from information_schema.routines r left join pg_namespace ns on r.routine_schema = ns.nspname left join pg_proc p on ns.oid = p.pronamespace and r.routine_name = p.proname left join pg_description d on d.objoid = p.oid where r.routine_schema = :schema'
오류: p.proisagg 칼럼 없음
  Hint: 아마 "p.prolang" 칼럼을 참조하는 것 같습니다.
  Position: 34
(0sec)
Connecting relationships...............................................................(0sec)
Writing/graphing summary.INFO  - Gathered schema details in 0 seconds
INFO  - Writing/graphing summary
INFO  - Graphviz rendered set to ''
........(8sec)
Writing/diagramming detailsINFO  - Completed summary in 8 seconds
INFO  - Writing/diagramming details
............................................................(15sec)
Wrote relationship details of 60 tables/views to directory 'f:\schema' in 25 seconds.
View the results by opening f:\schema\index.html
INFO  - Wrote table details in 15 seconds
INFO  - Wrote relationship details of 60 tables/views to directory 'f:\schema' in 25 seconds.
INFO  - View the results by opening f:\schema\index.html
INFO  - StackTraces have been omitted, use `-debug` when executing SchemaSpy to see them

D:\a\apps\schemaSpy>

See Also

  1. How to Create an ER Diagram in DBeaver | InMotion Hosting : dbeaver 에서도 ER diagram 을 확인할 수 있다. 개인적으로 이쪽이 가장 간편하고 좋은 듯 하다.