あるふぁべっとがおおすぎる

ITネタとか勉強会とか色々

デブサミ2019 行ってきた | Advent Calendar 2019

IT系の勉強会行ってきた Advent Calendar 2019 - Adventar の5日目

去年も参考になるやつが多くて行ってよかった。
参加して印象に残ってる講義を中心にぺたぺた。

 

 

レガシー開発からモダン開発への挑戦

  • 構築時を知る社員は0でレジェンドの協力会社の人しか当時を知らない
    実物と異なる構成、現地に行かないとハード構成がわからない
    →オンプレ老朽化に伴いクラウド移行
  • サーバはペットではなく畜牛のように扱う
  • Terraform, Ansible, Packer の活用
  • 自動復旧
    SD→GitLabのWebhook→GitLabCI→再起動
  • Spring Bootアプリケーション起動が遅く、テストに時間がかかる
    Maven Surefire Pluginの活用
  • マイクロサービス向けのMicronautを使うことも検討

 

サポートを、上手く使って迅速解決!

  • バズってたあれの紹介
  • 正しい基本情報の入力
    質問種類/サービス/カテゴリ、言語、緊急度、質問者のリソース所有者
  • 課題の明確化
    障害と判断した状況:アクセス元やpingやブラウザやssh、実現したいこと
  • 状況の正確な共有
    いつどこで問題が発生、インスタンスID,リソースID,ARN,リージョン
  • 経緯の共有
    解決するために行ったこと、再現手順
  • スキルが高くないけど質問がうまい人は的確なやり取りによって解決が早い

 

Site Reliability Engineering at Google

  • SRE:元々はGoogleのシステム運用チームが考え出した言葉
  • Googleの中の話なので依存した部分も多く取捨選択が必要
  • 技術者同士の情報公開はかなり社内でされている
    Google検索エンジンのソースはエンジニアなら見れる
  • 業務時間の50%以上をソフトウェア開発やシステム安定につながるプロジェクト活動にする
    →50%ルールを脅かすシステムは開発チームへの運用作業の返却もしくは要員提供を要求する権利が存在
  • エラーバジェットの消費状況をモニタリングしてエラーバジェットが無くなる可能性がある場合は根本的な解決対策を講じる
  • Toilの削減、Burnout防止が重要、手間のかかる面倒な作業を自動化
  • 障害対応は問題解決を最優先。他人に頼ることを本人のスキル不足とはしない
  • 障害対応が終わった瞬間にみんなで発生要因、発生時の対応や反省点や改善策を文書化
    →個人を非難する内容は絶対に残さない。個人ミスを誘発するチームの責任
    →社内のすべてのエンジニアに内容が公開されている

 

エンジニア採用

  • RTC:2012年150名 → 2019年900名
  • セゾン:SIer部署とパッケージ部署がある。800人中500人がエンジニア
  • Repro:37名のエンジニア
  • 自社に応募してくれるエンジニアをどう集めるか
    どこを目指すのか?◯年後に◯◯やる!を役員と共有
    最初の募集は友達を口説く
    美しいソースコードを大切にする。メッセージを出す。こだわりポイントをアピール
  • メッセージの届け方
    人事担当からのメッセージを伝えるのは厳しいので現場の人に手伝ってもらう
    エンジニアは働く人を見てる
  • どこまで採用するのか?KPI設定どうやってる?
    素晴らしい人の採用できたらそれでよい
    現状を見つつどんなスキル、経験とかを重視するか現場と会話
  • エンジニアと共有するようにしてきたもの
    大事にしたい原則をミーティングで毎回話すような形で文化を作っていく
    この組織は誰に対して何を提供できるか?部のミッションとして公開
    よく話す。想いがあっても現状とは違う場合は多い
  • 募集者の見極めどうしてる
    カルチャーフィットややってることを外に出す
    選考担当者が偉そう問題

 

最後のエンジニア採用の中で話が出てた、文化は伝えていかないとミスマッチが生まれやすいみたいなのは印象的でした。

文化を作るの簡単じゃないからな…。

 講演資料のリンクは下記

デブサミ2019、講演関連資料まとめ:CodeZine(コードジン)