20210124 July Tech Festa memo

セミナーメモ

July Tech Festa 2021 winter - connpass

受講セッションメモ

E2: IT監視とは何か 監視エンジニアのスキルと成長

  • NewRelic の九龍真乙さん
  • 資料
  • 日本でのシステム特性と監視の概要説明
    • SIer, ユーザ, MSP といった会社が分かれていることでの監視特性
    • 監視とはなんであるか
    • 今後の監視のあり方
    • などを説明
  • オブザーバビリティ
    • 「監視」は異常検知、オブザーバビリティは「原因究明」（のための可観測性）
    • 全体的な可観測性がポイント
  • SRE
    • 日本のレガシー企業ではSREの話をしてもピンと来てもらえなかったが、今回の説明でそのいったんが見えた気がする
    • 組織的な課題（SREのような横断的人材を配置するようになっていない）
    • 開発者が運用のコードを書かない

D5: Documentation as Codeで継続的なドキュメント運用を実現する

 私が3つ目の専門軸としてSREを選んだ理由

 資料  専門性を活かして希少性のある人材へ   * 専門軸を３つ作る

その他

20210107 インフラエンジニアBooks#5 石井遼介氏と読む「心理的安全性のつくりかた」

セミナー情報

メモ

  • 心理的柔軟性
    • 心のしなやかさ
    • 役に立つことがポイント
    • 行動に集中する
  • 心理的安全性の「４つの因子」
    • １．話しやすさ
    • ２．助け合い
    • ３．挑戦
    • ４．新奇歓迎
  • 心理的非・安全性
    • 罪と罰でのチーム運営
    • 報告すると仕事が増える
      • 言ったもの負け
    • 話しにくいひと
      • レスポンスが遅い人
      • 忙しそうに見える人
      • 感情的になる人
    • キレるとメンバが行動してくれるようにみえる
  • 役職で心理的安全性の捉え方が異なる
  • 昔の言い方
    • 風通しがいい職場
    • ワイガヤ

Twitter

2020年の振り返り

その1:テレワークが主となったこと

3月末ごろから全面的にテレワークとなった。会社としては、オリンピック開催期間のテレワークを想定して準備をしていた。このためインフラ面では特に大きな問題もなく万単位の人数の社員がテレワークを開始できた。そして2020/3から2020/12現在までの9か月、特に問題なく(自分の)業務遂行ができている。

2019年のセミナーでMitchell HashimotoがHashicorpには明確なオフィスはなく基本的にテレワークだと言われていた。この時は、HashicorpのようにOSSを展開し全世界に開発者がいるような会社の話だな、と思っていた。

9か月もの間、業務遂行がうまくいっているのは、従来からの開発チームとしてのプロセスやツールがテレワークでも耐えうるものだったのだ思う。ポイントとしては以下の3点。月並みだがテレワークでの分散開発が可能な状態となっていたことになる。

  • 見える化
    • Redmine, GitLab, へ開発情報の記録、保存
  • リズムの維持
    • 朝会、定例会、振り返り
  • 従来通りのコミュニケーション
    • MS-Teams を使ったホウレンソウ

メンバおよび私は以下のような点でテレワーク化での意義を得ていると思われる

  • 子育てに臨機応変対応
  • 通勤に片道1.5時間かかっている人の有効時間活用
  • コミュニケーション苦手な人が意外と上手くやってる(と思われる)
  • 病気や怪我でもテレワークで仕事が可能(後述)

このようにテレワークについては肯定的にとらえている。課題があるとしたら以下のようなものが挙げられる

  • 元のようにオフィス集約型に戻ることはあるのか
    • 感染症問題が解決したら元のようになるのか
    • 戻さない場合、現状のオフィス施設はどうするのか
  • オンボーディング
    • 現状のメンバはよく知っているものばかりであるが、新しいメンバを受け入れる際の取り組み方

その2:様々なセミナーやカンファレンスにたくさん参加できた

参加したセミナーやカンファレンスの領域

　全体の感想

  • リモート開催となったことでの参加し易さ
    • 2019年のセミナーはほとんどオフラインで会場へ行く必要があった。現場に行ってセミナーを受講する意義は大きいが、50歳を超えると業務後に現場へ行き受講する負担はそれなりにあった。
    • 2020年はSRE Next までが現場での受講であった。
  • 技術的関心時の変化への対応
    • 受講する数が多くなってくることで関心事が広く知ることができる
    • 有識者が同じような課題感を話す点を押さえていく
  • クラウドネイティブの導入の大変さ
    • 今後の方向性としてクラウドネイティブが各社からソリューションとして表明されているが実際は様々な　面で課題があり、容易にLift&Shift 仕切れていないことがわかる
    • エンタプライズ系でのコンテナ化について、単なる技術的移行だけではなく経営層から現場まで考え方のパラダイムシフトが必要

その3:2020年困ったこと

  • qrunch サービス終了
    • 使いやすいサービスだったが10月にサービス終了となってしまった
    • QiitaにUpするほど公式度が無いようなログ的なものは気楽にupしていた
      • とりあえず、qrunchに書いていたログは、はてなに移行
    • zenn のアカウントも作ってあるがまだ使っていない
  • 骨折入院2回
    • ３月と11月、2回も骨折入院
    • 腰を複雑骨折し11月は大手術となってしまう
    • この件は別途ログする予定(3月分はこちら)
    • テレワークが功を奏して体が動かなくても休職とかすることなく仕事ができた
  • 春の緊急事態宣言前後のマスクやハンドソープ、トイレットペーパーの品薄

以上

20201221 Infra Study Meetup #9

セミナー情報

パネルディスカッションメモ

​

登壇者自己紹介より

​

  • IaC
    • 意識することがなくなってきた
    • コンフィグマネジメント
  • k8s
    • Operatorの発展を注目
      • 4-5年前からk8sは「使える」ものであったが、一般的に足りない面が見えてきた
    • サービスメッシュ、カオスエンジが進んできた
  • SRE
    • 組織作りがポイント
    • オブザーバビリティ
    • 新たな価値を出すSREを目指す
  • Edge
    • バズった
    • 実態は何も進んでいない
    • 研究では進んでいるように見えているが。。 ​

Edge

​

  • 実際にどのように使われているか
    • 期待に対して進んでいない
    • オンプレ領域では使われているが、それがEdge？という感じ
  • 当初思い描いていたようなものにはなっていない
    • DoCoMoとか始まった、といっているだけ
  • どういう立ち位置？
    • 何か独立したもの？ or 従来システムの延長？
    • ユーザの近くに置くこと
      • クラウドの利便性をユーザの近くに備えよう、というものだが、今は単にユーザの近くにコンピューティングをおいているだけ
    • 人々の身近なところに、というのは時代ごとにあった（ユビキタス）
      • 動的、IaC、クラウドネイティブとかつながると、いう感じ
    • k8sで抽象化
      • コンテナが動的にデプロイされる。近傍やGPU必要なものとか要求に応じてデプロイされる
      • エッジ、フォグの前段階でマルチクラウドが出ている（青）
      • 階層型DC
      • 複数のクラウドの階層化、とかk8sで実現されるか。数年（青）
      • クラウド間のオーケストレーション仕様としている
    • 標準化されたリソースマネジメント、デプロイ
      • RH が取り組みを始めている
      • ドキュメントはまだまだ
    • 階層型DCができたとして
      • コンフィグマネジメントとか複雑になるのでは？
      • オーケとの役割分担は？
      • k8sがそれをになっていると思う（mizzy)
      • コンフィグマネジメントは下の領域になる
        • エッジはコンピュータリソースが限られる
      • パラダイムシフトがでる乖離が大きくなることを理解すべき（菊）
        • 家のブロードバンドとかのライフサイクル
        • 組み込み系のパラダイム必要
        • 「つないで動く」とするのは結構難しい
        • k8sのコントロールプレインとデータプレインのようなアーキはわかりやすい
        • キャズム超えの技術が出てくる ​

抽象化

  • 研究者は先を見据えているが
    • 理想形は共有されている？
    • 抽象化レイヤ(k8s)とすると。。
    • k8sをつくるIaC って
      • 規格を統一するのがいいが無理だろう
      • IaC用の言語ができればいいだろう
      • 中間言語を考えている(mizzy)。実行環境に合わせて生成する
    • DCにk8sを構築するのと分散側にk8s構築する差異はあるか
      • 構築に差異はないが、クラスタのサイズ（DC、建物、。。）
      • 建屋ごとにクラスタがあるのが理想形
      • ルーティングプロトコルのように中央集権的ではなく、分散処理する
  • ICN
    • 失敗した
    • k8sのマスタが階層的になるとか、必要じゃないのか
    • SDNはポシャッタ（早すぎた）
  • クラスタ使っているひと
    • アドミナリティ
      • どの拠点にもデプロイできるようなもの
    • DCとEdgeをつなぐ技術がない（考えてる人がいない）縦のつながり
      • OpenFlowはそんな感じのものだった（当時はまだいらなかったので失敗した）
  • 全体最適について
    • 多段になっている場合、コンフィグが反映されるようになってほしい。サービスメッシュ、分散トレーシング
    • 可観測性が急激に発達してきている→マルチクラウドとかにも広がってほしい
  • NWコンフィグ
    • このあたりの知見は重要
  • mizzyさん
    • 抽象化（人間のため）
  • 青山さん
    • 分散のワークロードを動かす、という点を考えてみたい
  • 菊池さん

以上

20201210 OpenShift.Run Winter 2020 #11

セミナー情報

​

セッション

​

気をつけたいKubernetesとの付き合い方

​

  • 資料
  • Kubernetes はコンテナクラスタ運用をよしなにやってくれるが、その特性を知っていないとトラブル、という話
  • 注意すべきいくつかのポイントがあがっている
    • オートスケールについてはいろいろ考慮が必要だろう ​

エンプラもOpenShiftでプラットフォームを作りたい　〜「OpenShiftという『ミドルウェア』が入ったサーバ」にしない為に〜

​

  • 資料
  • IBM の方
  • システム更改時に、「DX」を御旗にプラットフォームをOpenShiftへ
    • OpenShift の活用ができない可能性あり
    • 目指す姿が、役割・ステークホルダによって異なっていると完成しない
  • だれも無価値な基盤を作ろうとは思っていないが
    • k8s がこれまでのテクノロジとは考え方がかけ離れていることに気づいていない
  • ステークホルダとのすり合わせ
    • k8s利用、としてのプラットフォーム設計をする
    • プラットフォームとして目指す姿を定義する
    • 責任境界の明確化
    • 共有と分離設計
    • 生産性と管理性のバランス

​

感想等

​

  • コンテナ案件の話をしている際、このミドルウェアは従来通り５年から10年保証してくれるのか、などのトラディショナルな話が出てくることがある。k8sは３か月で更新される、という話が出ると「使えない」とも言われる。
  • 案件において、LiftするものShiftするもので説明の仕方を変えたり、従来の情シスとは異なる考え方も必要なことを説明したりする必要があるだろう

20201205 IBM Cloud Festa Online 2020

IBM Cloud Festa Online 2020

セミナー情報

RoomA セッション

17:30-18:00 A-5 OpenShift x IBMがもたらすハイブリッドクラウド戦略

RoomB

14:00-14:50 Edge Computing/TAPE B-1 AIとオープンソース、そしてテープアーカイブの話

15:00-15:50 5G/Edge Computing B-2 5G/Edge Computingの動向

感想等

  • IBMが社内外向けに最新の動向などを説明するカンファレンス
  • 気になっている、IBMのクラウドネイティブ対応や5G関連の情報を得ることができた

20201125 Infra Study Meetup #8 memo

セミナー情報

セッション

基調講演「インターネット基盤技術の研究と企業における未来を見据えた研究組織設計と実践」

  • 資料
  • 講演者
  • クラウドホスティング企業の研究者
    • テクノロジを生み出し叡智として永続化して改善を繰り返す
    • 実はエンジニアは研究相当のことをやっている
    • 効果の整理は難しい
  • 情報系研究者・研究チームの存在が必要
    • 一般化して研究コミュニティとかに落とし込み
  • 社内での信頼関係を構築していくことが重要
  • 企業研究者の貢献とは
    • 貢献が「間接的」と見られる
    • 形式知としてアウトプットしていく必要あり
  • この説明自体の言語化も研究者としての役割
  • チーム間での信頼関係を構築し役割を理解していく

LT4「コンテナ型仮想化技術におけるネットワーク分離の研究開発事情」

感想

  • 企業の研究者のあり方を言語化して説明していただき、納得感があった