元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2018/02/15

デブサミ2018「GitHubの開発フローにおけるサポートエンジニアの役割」講演メモ #devsumi


GitHubで働いている前職の同僚がありがたいお話をしてくれるとのことで、セッションを聞きに行った。

登壇前に、手汗ぐっしょりの彼と握手をしましたが、面白い話が聞けたので、そのメモを残しておきます。


  • Hayato Matsuura
    • GitHub / Enterprise Support Engineer
    • Yakst主宰
    • 最近「入門Kubernetes」を翻訳したよ

GitHubとは

  • スローガン
    • GitHub is how people build software
  • ユーザ数: 2700万+
  • リポジトリ数: 7700万+

GitHubを支える技術

  • ベアメタルサーバで運用
    • IOバウンドなので、クラウドだとパフォーマンスが出ない
  • Rails + kubernates + MySQL + redis + Git + ...(etc.
    • ミドルウェアとしては、固めでスタンダードな選定

Gitリポジトリ冗長化システム
  • Spokes
    • 昔はDGitという名前で、DRBDで冗長化してた。これだとスケールしないので改善。
    • Spokesでは、プロキシ型のアーキテクチャをとっていて、バックエンドのストレージにデータを分散配置している

Kubernatesによるコンテナ管理
  • モノシリックな構成だが活用している
  • APIやWebなどユーザが接続するフロントのサーバで活用

GitHubでの開発の流れ

  • まず、Markdownで提案書を書いて、PRを送る
  • みんなの合意が取れたらマージして開発を進める
  • 実際の開発では、issueやprojectの機能を使い、GitHub自体で完結する開発プロセス
  • GitHub Flowを使ってスタンダードな感じで進めている

GitHubでは、デプロイしてからマージする
  • 通常だとマージしてからデプロイだけども
  • masterは常にデプロイ可能な状態
  • 動く状態を確認してからマージする
    • 一時的にでもバグの混入を防いでいる

ChatOps
  • Slack + hubotを使っている
  • いつも24時間、誰かがデプロイしている。
    • ぶつからないようにデプロイキューを作っている。
  • hubot自身が仮のブランチも作ってくれる。
  • カナリアリリースに対応済み
  • hubotがデプロイした後、運用管理システムで状態のチェック
  • 問題なさそうなら、hubotがマージを促してくれる

GitHub Enterpriseとは

  • 仮想マシンに載ったGitHub.com + 管理機能 + α
  • 仮想マシン => AWS、GCP、OpenStack、VMwareなど
  • GitHubとの差異はロゴくらいしかなく、基本的に同じ使い勝手となるようにしている

GitHub.comのお問い合わせ

  • Git/GotHubの使い方
  • 間違って消したリポジトリの復旧依頼
  • 要望、バグ報告など

GitHub Enterpriseのお問い合わせ

  • 企業のバージョン管理システムの担当者が相手
    • ユーザとそのアクションを管理する方法
    • レプリケーション設定
    • パフォーマンスの問題解決
    • 管理機能のバグ報告・機能改善要望など

GitHubのサポートの考え方

  • あえてサポートをレベルわけしていない
    • T1, 2, 3とかそういうのは無い

サポートエンジニアの働き方

GitHubの社員は世界中に分布している
  • タイムゾーンを3つにわけて、それぞれのエリアのサポートエンジニアが8時間働く
    • 世界中のお客様に対して24時間体制でサポートしている
  • 日本に限り、日本語のサポートをしている
    • ローカル言語なので、残念ながら平日9-17時でやっている

バグ報告
  • issueを作成して報告
    • 不具合の再現手順
    • 発生条件、エラーについてまとめ
  • 開発のIssueの3割は、サポートエンジニアが作成
  • しかし、場合によっては修正の必要に迫られることもある

日本に開発者がいない問題
  • そもそもAPACに開発者が少ない
  • アメリカ・ヨーロッパに多く、時差によるコミュニケーションのオーバーヘッドが発生
  • マルチバイト文字の扱いなど(不具合が残っているケース)

マルチバイト文字の扱いに関するバグの例
  • ライセンスファイルにマルチバイト文字が入るとエラー
  • 特定のGraphQLクエリにマルチバイト文字が入るとエラー
  • マルチバイト文字を含むファイル名のdiffページが特定の条件下で文字化け

サポートも開発したい気持ちもある
  • ユーザからの声を直接聞いている
  • 自分がユーザならここを直したい
  • サポートだけだと新しいことを覚えにくい
  • サポートエンジニアの主業務はサポートだが、開発も推奨
    • GHEのPRの4割近くはサポートから
    • 松浦さんも管理画面のモニタリングのグラフの生成アーキテクチャを変更するPRを投げている

サポートエンジニアはお客様のSRE
  • SRE: 自社サービス
  • サポートエンジニア: お客様のサービス
  • SREは50%以上を開発に時間をあてるべき
  • サポートエンジニアも同じように働くべき?
    • 50%と言わないまでも開発すべきだと考えている
    • ソフトウェアの中身を理解することで品質を上げる
    • ユーザの声を直接FB・反映できる
    • 開発陣の着手を待たずリリースできるかも
    • チケット量が減った際のサイドプロジェクトとして
  • サポートエンジニアも積極的に開発に関わるべき
    • 開発したいエンジニアのキャリアパスとしてもあり
      • インフラやデベロッパーの方など

お知らせ

  • 企業のお客様にもGitHubを使って欲しい
  • 日本語サポートあります
  • 日本語ドキュメントも出ます(いつかはまだ未定)
  • 日本語Webサイトを3月に公開予定
  • 2018/6 にSatellite Tokyoを開催するよ

追記

資料が公開されています。

sakurai_youheisakurai_youhei 2018/02/16 08:32 メモを見るだけでも面白そうな内容、純粋に「いいなぁ」と。

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

トラックバック - http://d.hatena.ne.jp/rx7/20180215/p1

オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)