技術と英語で立ち向かうOSSとエンタープライズの世界 テクニカルサポートエンジニアとい う働き方 Kento Yagisawa (ひよこ大佐) Technical Support Engineer - Ansible 1

自己紹介 Agenda 2 八木澤 健人 (やぎさわ けんと) テクニカルサポートエンジニア (Ansible) レッドハットにTwitter転職して2年以上経ちました。 社内でも社外でも、だいたい「ひよこ大佐」と呼ばれています。 Twitter: @hiyoko_taisa GitHub: github.com/hiyokotaisa/

北極に埋められる人（ひよこ）になりました Agenda 3

Agenda 4 『Ansible 構築・運用ガイドブック』 書籍・電子書籍版 Amazon・全国書店にて好評発売中(らしい) 『Ansible実践ガイド』もオススメ

Agenda 今日のおしながき 5 ● インフラエンジニアからテクニカルサポートエンジニアへ ● 技術と英語で世界と戦う ● オープンソースとの関わり ● トラブルシューティングのためのTips

6 インフラエンジニアから テクニカルサポートエンジニアへ

インフラエンジニアからテクニカルサポートエンジニアへ SES(SIer常駐)からレッドハットへ 7 SIer時代 転職後 ● ITインフラの設計・構築など ● 業務で英語は使わない ● 1ヶ月に1度は派遣元に帰社する ● 資格取得できたかどうかで評価 ● Ansibleのテクニカルサポート ● ほとんど英語 ● OSSへのコントリビューションや コミュニティへの参加も評価対象 Twitter転職

インフラエンジニアからテクニカルサポートエンジニアへ 転職しても活きるスキル 8 転職したからといって「ゼロからスタート」ではなく、それまでやってきたことは確実に活きてくる ● サーバーやネットワーク機器などのITインフラの設計構築で培った知識 ● PowershellやShellscript、Ansibleを使った経験 ● 「なんでもやってみよう」というチャレンジ精神と知的好奇心 掛け算できるスキルを持っておこう

インフラエンジニアからテクニカルサポートエンジニアへ スキルを増やすためには？ 9 ● 「知的好奇心」というコアを持つ ● 知らないことを貪欲に吸収するためには「知的好奇心」が必要不可欠 ● 自分のキャリア・学習プランに責任を持つ（オーナーシップ） 転職もひとつの方法だが、絶対的な正解ではない

インフラエンジニアからテクニカルサポートエンジニアへ テクニカルサポートエンジニア(TSE)とは 10 お客様の抱えている 問題 / 課題 / 疑問 を技術的側面から解決するプロフェッショナル お客様からの製品に関するさまざまな問い合わせに解決策を提示する ● Ansible Towerをアップグレードに失敗する ● 外部ロギング連携で一部のログが欠落する ● LDAP連携で特定のグループのユーザーのみTowerの管理者権限を割り当てたい ● ios_configモジュールを実行した際にエラーが発生する 問い合わせ例 (Ansibleの場合)

インフラエンジニアからテクニカルサポートエンジニアへ ケースオープンからクローズまでの流れ 11 問い合わせ受付 （ケースオープン） 解決策/ワークアラウンド提示 問題調査 問題解決 （ケースクローズ） お客様にケース番号送付 / Case Ownerが対応 ログの送付 / 検証環境の構築 / コードの追跡 Engineeringチームと連携することも NPS(Net Promoter Score)による顧客満足度の測定

インフラエンジニアからテクニカルサポートエンジニアへ TSEに求められるスキル 12 ● お客様の問題を特定し解決できる「技術力」 ● お客様の問題のヒアリング、開発者や他のスペシャリストとのコラボレーションなどの 「対人コミュニケーション能力」 ● 難しい状況でも折れない「メンタル」 ● お客様やチームメンバーと適切なコミュニケーションや情報収集ができる「英語力」 ITエンジニアとしての総合的な能力が求められる

13 技術と英語で世界と戦う

技術と英語で世界と戦う なぜ英語が必要なのか？ 14 ケースワーク リモートでの トラブルシューティング 上司・同僚との コミュニケーション ( Slack / IRCなど) GitHubでのやりとり ナレッジベースの作成 最新情報の キャッチアップ Writing / Reading Speaking / Listening

技術と英語で世界と戦う 求められる技術的な知識 15 製品に対する知識 (Ansible) Windows Linux全般の知識 ネットワーク Python PostgreSQL AWSやAzureなどの クラウド環境 LDAP / SAML / OAuth その他 ITインフラに 関わる幅広い知識

技術と英語で世界と戦う 「技術力」+「英語」で世界と戦う 16 ● 世界中のお客様の問題に対処する ● 言語の垣根を超えて世界中の優秀なデベロッパーやコントリビューター・同僚と一緒に仕事をする ● コミュニティ活動やOSSへのコントリビューションなどが捗る さらなる成長につながる

17 オープンソースとの関わり

オープンソースとの関わり Red Hatが他と違う点 18 ● OSSをベースにサポートを提供している ● オープンなカルチャー ● UpstreamとDownstreamという考え方 ● コミュニティとの関わり OSSの文化やコミュニティに対する理解が必要

オープンソースとの関わり 19 一般的なバグフィックス サポートエンジニア 開発チーム ユーザー プロダクト バグの修正・変更 調査・報告 問い合わせ

オープンソースとの関わり 20 OSS(Ansible)の場合 サポートエンジニア 開発チーム ユーザー (Red Hatのお客様) プロダクト リリース Issue作成 場合によってはPRも 問い合わせ GitHub リポジトリ Issueを元に PR作成 コミュニティの コントリビューター コミュニティの ユーザー Issue作成

オープンソースとの関わり OSSを前提としたカルチャー 21 ● OSSでは、「コミュニティ」という存在がある ● 有志のコントリビューターやユーザーがいる ● Red Hatのプロダクト(Downstream)だけでなく、コミュニティ全体(Upstream)に還元する コミュニティと共に成長していく

22 トラブルシューティングのためのTips

トラブルシューティングのための Tips トラブルシューティングの方針を決める 23 システムの重要度を確認する ● 問題の影響度を確認（システム全停止なのか、軽微な不具合なのか） ● 即時復旧を優先するか、時間をかけた原因追求をすべきか検討 ● 作業中に問題が発生した場合は切り戻しを検討 問題が起きた状況を特定する ● 発生時間、事象、発生頻度、再現性があるか、環境（OSやハードウェア構成)などを確認 ● 似たような事例がないかナレッジなどを確認

トラブルシューティングのための Tips トラブルシューティングTips 24 問題の切り分けと再現が9割 ● 問題が発生しているレイヤーとコンポーネントを特定 ● 切り分けはひとつひとつ確実に（思い込みは厳禁) ● エラーメッセージは友達 ● 事象が再現できれば勝ち 仮説を立てて証拠を集める ● トラブルシューティングはミステリー小説の謎解き 仮説を立て、証拠を集めて検証する

トラブルシューティングのための Tips TSEに向いている人 25 ● トラブルシューティングが性癖な人 ● 「なぜだろう？」と疑問に思ったことを調べ、試してみるのが好きな人 ● コミュニティとの関わりやオープンソースの文化に理解がある人 知的好奇心をもって問題解決ができる人

26 Q&A?

linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you 27