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を開催するよ
