Upgrade to Pro — share decks privately, control downloads, hide ads and more …

20200319_出張!Railsウォッチ in 銀座Rails#19

20200319_出張!Railsウォッチ in 銀座Rails#19

2020/03/19に銀座Rails#19で発表したスライドです。
https://ginza-rails.connpass.com/event/166729/
週刊Railsウォッチ: https://techracho.bpsinc.jp/tag/%e9%80%b1%e5%88%8arails%e3%82%a6%e3%82%a9%e3%83%83%e3%83%81

Masato Mori

March 19, 2020
Tweet

More Decks by Masato Mori

Other Decks in Programming

Transcript

  1. About Me
 • 森 雅智: @morimorihoge
 • BPS株式会社でRailsの受託開発チームをやってたり、週1大学非常勤で Web開発を教えてたりします
 •

    Ruby/Rails歴は11年くらい。Web開発は17年くらい
 • 銀座Ralis #10でActiveRecordでVIEWを使おうという話をしました
 About BPS & TechRacho
 • Web受託開発や電子書籍製品開発をやっている会社です
 • TechRachoという自社技術Blogを運営しています
 ◦ 3年ほど前から平日毎日更新してます
 ◦ https://techracho.bpsinc.jp/ • お仕事相談、転職相談、TechRachoへのご意見など気軽にどうぞ
 ◦ https://www.bpsinc.jp/ 2

  2. これまでの出張Railsウォッチのピックアップテーマ
 • Rails6新機能特集
 ◦ 銀座Rails#12: 複数DB対応
 ◦ 銀座Rails#13: ActionText、Trix
 ◦

    銀座Rails#14: ActionMailbox
 • Railsアプリケーション開発に関する雑多なテーマ
 ◦ 銀座Rails#15: production、development、staging環境につ いて
 ◦ 銀座Rails#16: 機能開発の設計レビューについて
 ◦ 銀座Rails#17: リソース管理スコープについて
 4
 ※過去のスライドはTechRachoにて公開しています。「TechRacho 銀座Rails」あたりで 検索するとヒットしますので興味のある方はどうぞ

  3. 例のアレの影響
 6
 • 世間的に人が集まること自体が忌諱される状況に
 • 仕事の進め方にも大きな影響が出ている
 ◦ 突然のリモートワーク推進
 ◦ 勉強会やカンファレンス

    イベントの中止・延期 
 ◦ F2Fでの打ち合わせを禁止 するところも
 ◦ 社内でも人数の多い会議や歓送迎会の中止 などなど
 • 開発プロジェクトにも延期や中止などの影響が出始めている
 • 現在進行系で日々状況が変わっているが、少なくとも現時点でいつ収束するのか の予測は立たない状況

  4. Webエンジニアへの影響はどうか?
 • 既にリモートワークやオンラインベースの業務の進め方に対応していた開発チーム では、他業種に比べると開発の面では大きな影響はない
 ◦ F2Fを大事にしていたチームについては色々と試行錯誤の声が聞こえて来るが、ベストプラクティス の共有などもよく行われているので慣れていけば恐らく問題ない(1ヶ月くらいできっと慣れていきそ う)
 9
 それって本当?


    • もし仮に外出禁止や隔離措置が取られたとしたら?
 • 確率は低いと言われているが、重症化して入院者が出たら?
 • どうしても現地に行かないといけない仕事はどうなる?
 特に、スタートアップ等で少人数で運用しているチームの場合、
 そこまで「いざというときのための準備」がされていないことが多い

  5. Railsプロジェクトで一部の人に偏りそうなもの
 • 開発系
 ◦ 難しい機能の設計や開発 タスク
 ◦ コードレビューや本番リリース作業
 • 運用系


    ◦ リポジトリのmaster branchへのmerge / 本番deploy権限
 ◦ 本番環境のAWSやGCPリソースを閲覧・更新する権限 
 ▪ 構成にもよるが、一部の作業はPowerUserAccess権限だけだと実行できない(EC2インスタン スにIAM Roleを付与しようとしたらIAM Roleが参照できないとかがありがち) 
 ◦ 連携サービスのアカウント、及び 通知メールの共有
 ▪ クレジットカード課金失敗連絡を誰も見ていなかったらサービスが止まった、などはありがち 
 ◦ credentials.ymlのRAILS_MASTER_KEY 
 ▪ 頻繁に更新することはないが、たまに更新が必要になるため忘れやすい 
 ▪ 連携サービスのAPIキーを再生成したりしたときに詰む可能性があるので注意 
 11

  6. 弊社(BPS株式会社)での対応例など
 • 開発系
 ◦ いざという時のために、普段開発には入らないがプロジェクトの情報だけは共有しておくメンバーを 1人以上予備アサイン しておく
 ◦ 本番リリース作業などは手作業が必要なら手順化し、リポジトリWiki等にドキュメント化 


    • 運用系
 ◦ サービスやリソースアクセス用の アカウント情報は必ず2名以上が持つ ようにしておく(アカウント情 報ロスト対策としても有効) 
 ◦ 障害対応の履歴や記録はなるべく 具体的なコマンド履歴やスクリーンショットレベルでチーム内に 共有しておき、いざというときに後から調べられるようにしておく 
 ▪ 「どうやって障害と判断したのか 」「どうやって障害復旧を確認したのか 」は具体的な記録に残 しておくと、後から同じ作業を別の人が追いかけやすくなるので良いです 
 12

  7. まずはこれだけでもしておきたい
 • まずは人的なSPOF(単一障害点)の洗い出しをする
 ◦ 「リスクがあること」を可視化し、共有する のが大事
 • 「もしこの人が突然作業できなくなったら・・・?」という前提で、ワーストケースのシ ナリオをいくつか描いてみる
 •

    描いたシナリオを、Product Ownerや偉い人(少なくとも何かあった時に責任が取れ る人)に共有し、どこまでならビジネス上許容できるのかを確認してもらう
 • 許容できるレベルに達していないのであれば、時間なり予算をつけてもらってなん とか許容レベルまで持っていく
 15
 特に、障害対応関連の潜在リスク は開発チーム側にしかわからないものもあるので、開発サイドから Alertを上げていくのが良いと思います