(参加メモ)GitLab Meetup Tokyo #16: 新年度応援

4/24(水) に行われた以下勉強会の参加メモです。
ひとまず "資料を集めておいた" というものです。得たことを思い出すのに利用いただければありがたいです。

AGENDA

18:30 開場・19:00 開始

(Initialize)

18:30-19:00 GitLab Tokyo 受付

同じビルで他のイベントがあったようで、勘違いして行列に並んでしまったが、無事に定刻通りの会場入り。

19:00-19:05 GitLab Tokyo GitLab Tokyo/GitLabのご紹介

  • 会場提供のPLAID社の方より、会場と会社の説明。
    かなり GCP を使っている、トノコト。
    https://plaid.co.jp

  • フードスポンサーはアイリッジ社。 O2Oってなんだろう?って思いましたが、調べてみたらなるほどと思いました。 https://iridge.jp

Sessions

19:05-19:25 GitLabでできること&GitLab 12.0の改善点

@tnir さん

  • GitLab Tokyo の最近と今後

  • パッと見、なんでもできそうですごい、と思った。6枚目のスライドが圧巻。

19:25-19:55 (New Relic) SRE and APM (仮)

@csk さん

  • (いい話だった...DevOpsの歴史と、これからの話。・・・資料公開を期待・・・)

19:55-20:25 GitLab Runner autoscaling

@sue445 さん

  • スペックを上げてクラウドで殴るCI

  • 運用の知見満載の資料。圧巻であんぐりと開いた口が塞がらない。Oh, my god ! と本当に思った。サービスマネージャを目指すうえは、精進せねばと。

LTs

20:25-20:30 ふんわりReview Appsでデプロイプレビュー

@Rena_moo さん

20:30-20:35 GitLab CI/CDとECS Fargateでリリース作業が楽になった話

@8rfx さん

20:35-20:40 iOSとGitLab-CI

@417_72ki さん

  • iOS And GitLab-CI

  • iOSプロダクトの運用について知見を得た感じ。適材適所を目指して辿り着いたのかなと思った。(というか、このあたり自分が知ってることが少なかったので、聞いたことが新しいことばかりで仰天してた)

  • 補足

20:40-20:45 GitLabサーバーのモニタリング

@yteraoka さん

  • GitLabサーバーのモニタリング

  • 「自分の見たい情報は自分でDashboard作るのが良い」と、CIにかかる時間を見るのに工夫をした話。モニタリングの本質を衝いた経験(敬虔)談+アルファを聞けた。追究・求道とはかくありたい、なと。

  • 補足

20:45-20:50 新人がGitを使えるようになるために育成レポートをGitLabで管理してみた話

@takamii228 さん

  • 新人がGitを使えるようになるために育成レポートをGitLabで管理してみた話

  • 今回のサブタイトル「新年度応援」に最も沿った、発表者本人も言ってましたがライトな、それでいて「最初って、こうですよね」という内容。圧倒され続けていたが、最後でなんか安心した。

  • 補足

ぼくのつぶやきから

https://twitter.com/search?f=tweets&q=%23gitlabjp%20%40sogaoh&src=typd

ちょっとついていけなくて、まだまだ知見が浅いなーと痛感した。(普段使ってない、だけではない)
個人的にGitHubで管理しているものを、移してみようかなという気にはなっている。
本:GitLab実践ガイド を読んでから、だと、熱が冷めてしまうだろうから、GWが分かれ道になりそう。

(参加メモ)『失敗から学ぶ RDBの正しい歩き方』発刊記念!そーだいさんから直接学ぶ会

これは、 4/11(木) に行われた以下勉強会の参加メモです。
(スピード重視で、メモしたことを共有したいだけな感じです。一番見てほしいのは懇親会パート。)

AGENDA

会場説明 + α

  • ミクシィ 採用」で検索してね
  • 新人研修でMySQLのストレージエンジンを作った話

曽根壮大様によるご講演

  • アイスブレイク
    • @soudai1025 さんは mixi ヘビーユーザー
      • 運命の出会いも mixi
    • 本について
      • 書くのに2年くらいかかった
      • 何のために書いたか
        • 知識をつなぐため
      • 失敗談はなかなか本にならない
        • 失敗の共有はぜひやってほしい

資料

2つ目と3つ目のを抽出してマージした感じのが、今回の資料でした。

講演 かいつまみ(過ぎ...)

  • 第2章 失われた事実

    • (2014/)4/3 に返品があったら?1
  • 第7章 隠された状態

    • DBには事実を保存する
  • 第13章 知らないロック

    • MySQLPostgreSQLのロックには違いがある。ロックに限らず。
  • まとめ

    • データベースの寿命はアプリケーションより長い

懇親会

とても幸運なことに、 @soudai1025 さんといろいろ話ができた。
記憶に残っている2 ものを共有したいので列挙します。
()の中は「心の声」です。。

  • 第2版には 実行計画 の話が出るか?
    • まとめるのが難しい(って言ってたような違うかもしれないような...)
  • explain の読み方
    • 書かれてる本は少ないが、ある
      • (タイトルなんだったっけ...)
  • 参照系と更新系の分散は HAProxy にやらせるのが良さそう
    • フェールオーバーも、自動切り離しもするし
  • MySQL 8 の次のマイナーバージョンアップで check 制約使えるようになる
    • マイナーバージョンアップでそれをやるのが MySQL
  • Oracle は優秀
  • DBに関係ない別件
    • Amazon Linux 2 のインスタンスに mackerel-agent-plugins のインストールが できない、ような話を聞いたことありますか?
    • 断片的ですが
      • 「入門 子育て」出ますか?と「失敗(できんやろ)から学ぶ 子育て」どうですか?が近所から聞かれてました...軽く吹きそうに。

ぼくのつぶやきと、ハイライト3選

個人的にいちばん刺さったのはこのあたり。

備考


  1. 2014年4月1日:消費税率が 5% -> 8% になった日

  2. 自分にはビール 350ml 一杯がラリホーマです

(参加Blog)第2回 脆弱性対応勉強会(勝手に IPAテクニカルウォッチ ハンズオン)

これは、 3/30(土) に行われた以下勉強会の参加レポートです。

  • Twitter HashTag : (イベントページ上は明示されてなかったためか、投稿は少ない)

  • Note

    • ※本勉強会では、OSやフレームワークやライブラリなどといった階層の脆弱性を対象とします。WEBアプリケーション脆弱性については、対象としません。

感想

  • ハンズオンで Vuls を使ってみることができて、とっかかりを把握できたと思うので個人的にはかなり満足度が高い。先達はあらまほしきことなり。

  • Vuls 以外にも、脆弱性情報収集方法やCVSSなどの多くの情報を知ることができて、大変ありがたい会だと思った。感謝。可能であれば来月も参加したい。

  • Vuls のセットアップや脆弱性情報のアップデートは間違いなく自動化もしくは簡素化すべき作業だなと感じた。(Ansible Playbook に、余力あれば落とし込んでみたい気がしている)

資料

  • 進行用のメイン資料。勉強会の講義では「見せられないよ」の部分もオープンになっている資料を見ながら話を聞きました

IPAテクニカルウォッチ「脆弱性対策の効果的な進め方(ツール活用編)」

https://www.ipa.go.jp/security/technicalwatch/20190221.html

  • この中の、レポート(1.8MB) がハンズオンの材料
  • 資料は CentOS の環境を想定して書かれているが、ハンズオンでは Ubuntu にインストール
    • CentOS の OVAL 情報は ないRHEL のはあるけれど)ため、Ubuntu を選択トノコト

Vuls: VULnerability Scanner

https://vuls.io/ja/

  • OSS版公式サイト

https://vuls.biz/

  • 有償版。勉強会では終わりの頃に少しだけ触れられた

その他の有用に思った情報

  • 本題から少し逸れるので折りたたみの中に書きます。とてもきめ細かい。今後脆弱性情報を見る目が変わりそう。

    • セキュリティ設定共通化手順SCAP概説
      • 6つの共通仕様から構成される Security Content Automation Protocol
        • 脆弱性を識別するためのCVE
          • (Common Vulnerabilities and Exposures:共通脆弱性識別子
        • セキュリティ設定を識別するためのCCE
          • (Common Configuration Enumeration:共通セキュリティ設定一覧)
        • 製品を識別するためのCPE
          • (Common Platform Enumeration:共通プラットフォーム一覧)
        • 脆弱性の深刻度を評価するためのCVSS
        • チェックリストを記述するためのXCCDF
          • (eXtensible Configuration Checklist Description Format:セキュリティ設定チェックリスト記述形式)
        • 脆弱性やセキュリティ設定をチェックするためのOVAL
          • (Open Vulnerability and Assessment Language:セキュリティ検査言語)
    • 共通脆弱性評価システムCVSS v3概説
      • 脆弱性の深刻度を評価するための指標:CVSS(Common Vulnerability Scoring System)
        • 3つの脆弱性評価基準
          • (1)基本評価基準(Base Metrics)
            • 攻撃元区分(AV:Attack Vector)
            • 攻撃条件の複雑さ(AC:Attack Complexity)
            • 必要な特権レベル(PR:Privileges Required)
            • ユーザ関与レベル(UI:User Interaction)
            • スコープ(S:Scope)
            • 機密性への影響(情報漏えいの可能性、C:Confidentiality Impact)
            • 完全性への影響(情報改ざんの可能性、I:Integrity Impact)
            • 可用性への影響(業務停止の可能性、A:Availability Impact)
          • (2)現状評価基準(Temporal Metrics)
            • 攻撃される可能性(E:Exploit Code Maturity)
            • 利用可能な対策のレベル(RL:Remediation Level)
            • 脆弱性情報の信頼性(RC:Report Confidence)
          • (3)環境評価基準(Environmental Metrics)
            • 対象システムのセキュリティ要求度(CR、IR、AR:Security Requirements)
            • 環境条件を加味した基本評価の再評価(Modified Base Metrics)
        • AV などの符号は パラメーターの短縮表記 に用いられる

ハンズオン回顧

  • ここには、↑に書いたハンズオンの材料(IPAテクニカルウォッチ「脆弱性対策の効果的な進め方(ツール活用編)」)と異なる点・やっていて気づいた点のみを書きます。(勉強会での ..注意点.pdf に相当)

  • 実際にやった手順は↓にまとめます。(分けるのは、見映えの都合です。。)

4.4. 事前準備

  • /etc/profile の設定はPROXYを使わないので飛ばした
  • vulsuser の追加は、Ubuntu なので adduser でやらないとホームディレクトリが作成されないという罠があった
  • visudo で起動されるエディタ(Ubuntu デフォルトは nano)の設定変更を事前にやっておいた方が良い
    • update-alternatives --config editor -> /usr/bin/vim.tiny を選択した

4.5. 手動インストール

  • (1)(2)は取得に時間がかかるため、主催側で事前に踏み台サーバに取得してあるDBを複製して利用

    root@humidai:/tmp# time scp -i ~/.ssh/svr.key /tmp/cve.sqlite3 root@svr07:/tmp/

    • (1) 「JVN iPedia より 1998 年から作業年までの脆弱性情報を取得する」
    • (2) 「NVD より 2002 年から作業年までの脆弱性情報を取得する」
  • 今回の対象は Ubuntu18.04LTS であるため、Red Hat とはコマンドオプションが異なる

    $ cd $HOME

    $ goval-dictionary fetch-ubuntu

  • (3)OVAL の取得に時間がかかりすぎる(5分以上かかる)場合は、主催側で事前に踏み台サーバに取得してあるファイルを利用する

    root@humidai:/tmp# time scp -I ~/.ssh/svr.key /tmp/oval.sqlite3 root@svr07:/tmp/

  • (4)OSの脆弱性情報取得は25 分程度かかるため、主催側で事前に踏み台サーバに取得してあるファイルを利用する

    root@humidai:/tmp# time scp -I ~/.ssh/svr.key /tmp/gost.sqlite3 root@svr07:/tmp/

4.7. 脆弱性検知1

  • 2つのモード(ハンズオンで実習したのは a.)
    • a.Vuls を導入したサーバ自身に対してスキャンを行う「Local Scan Mode」
    • b.Vuls 管理サーバとリモート接続(SSH)をしたスキャン対象サーバに対して脆弱性検知する「Remote Scan Mode」

4.8. レポート確認(Vuls内機能)

  • TUI の操作を体感
  • わかるけど、VulsRepo の方が圧倒的に見やすいし使いやすそうに感じた

4.9. VulsRepo はやれず

  • 最新版 Vuls に対応できてない?
  • 個人的に、後日やっておきたい。

その他

会場提供のF-Secure 様より

  • 会社と紹介動画の説明をいただいた。
  • ハンズオンで疲れていたが、興味を持った。
  • 動画に日本語字幕を出せるのに「へー」と思った。
    • 確かに設定を変えていたのだが、自分のPCでそれをできない・・・

おわりに

やっぱり自分、この領域(セキュリティ)への関心が高い。もっとやっていきたいと思った。
人が安心してITを使える世にするには何ができるのか・何をすべきか、を考えていきたい。

備考


  1. 4.6. (参考)Dockerインストール は飛ばした

(参加メモ)人感センサでLINE通知する監視カメラを作ろう v2

※ アコーディオン部分の表示がどうにも意図した状況にならないので、  
 コードとコンソール出力に関しては別のページに分離しました。  
https://esa-pages.io/p/sharing/6641/posts/223/bd772f6e4d340d6cc532.html

Thoughts

  • 避けていたわけではないがこれまで触れる機会のほぼなかったIoTの領域に入り込むことができたようで、嬉しい。
  • 多くの新しいサービスやツールに入門できた。今後活用できるように、おさらいしたい。
    • SkyWay
      • 世界中のエンジニアのために、WebRTCの めんどくさい を引き受けるサービス
    • enebular
      • IoT製品・サービスづくりを包括的に支援する、開発・運用サービス
    • Line Notify
    • RaspberryPi

AGENDA

13:20〜13:40 オープニング

SkyWay & enebularについて

WebRTCの技術概要 / SkyWay の紹介

  • by @Tukimikage さん
    • 16枚目「WebRTCは総合格闘技」に対して、21枚目「SkyWayが提供するもの」で、ラクできそう、と思えてワクワクできる

IoTオーケストレーションサービス enebular のご紹介

  • by @wyamazak さん
    • 16枚目「複数のデバイスにリモートからデプロイ可能」でデバイス・ログを一元管理できそうに思えて、使ってみたくなる

13:40〜17:00 ハンズオン

資料: SkyWay+enebularハンズオン資料v2
特に大きな問題なく、ひと通り実現できて理解も深まった。
いや、そういえば、LEDはできなかったし、センサーを挿す位置がコーディングで固定されてて、後になってわかるまで検知しすぎるのを変えようともしなかった。

STEP1: enebularでWebアプリケーションを作成する

手順の通りでいけた。
1点だけ、補足説明あったところは以下。近日修正されるとのこと。

STEP2. Raspberry PiでSkyWay WebRTC GateWayの利用

これも特に難なくできた。
カメラに移った映像を画面で見れたのには小さな感動。

STEP3: enebularからLINE通知をしてみる

enebularからもPOSTリクエストからも、LINE 通知成功。

STEP4: 距離センサを利用してみる

ブレッドボードに対して外向きに差し込む は事後に最終的な記述に修正された。
そうなる前に、内向きに差し込んだ。
また、確かこのSTEPで、時刻合ってない問題に遭遇したと思う。
(手順書で触れられている)

STEP5: プロセスを永続化してみる

このSTEPでは、確か out of memory 問題に遭遇して、スタックトレースを手順書のコメントに共有した。
そのおかげで、pm2 の 余計なプロセスの削除方法も聞けて、それはそれでよかった。

早く終わった人演習とまとめ

ここまででだいぶ満足したので、チャレンジせずに先生が解くのをぼーっと見ていた。

17:00〜18:15 クロージング

片付け&アンケート

アンケートは、颯爽と回答しておいた。(Googleフォームだった)
分解して部品を返却。
再度、RasPiのシャットダウン。今日は手順をなんとなく覚えた。

懇親会

ありがたくも Pizza その他を振舞っていただいた。
本当におなかいっぱいになった。

Others

  • 入口がわからず、ちょっと遅刻してしまった。
  • Mac用のUSBの有線LANアダプタをお借りした。ありがとうございました。
    • 午前に届く想定だったが、間に合わなかった。。
    • 帰宅後届いてた、USB - Type-C アダプタはこちらです...

      20190323_adapter.PNG (5.4 MB)

(自分用Note)ITIL v3 Foundation かいつまみ

もうすぐ ITIL 4 が出るらしいが、知識体系の整理のために書き出す。
これからやっていきたいことのためにITSMのポイントの把握も再確認しておきたいと思い。

base reference

  • ITIL®V3ファンデーション[日本語]
    • Van Haren Publishing発行, ISBN: 978-90-8753-061-7 ※販売終了

サービス・ライフサイクル

次のことについて洞察を提供する組織モデル

  • サービスマネジメントの構造
  • さまざまなライフサイクル要素の関係
  • ある要素が変更された場合に、ほかの要素およびライフサイクル・システム全体に及ぶインパク

Figure(1) : サービス・ライフサイクル

001.jpg (715.3 kB)

サービスストラテジ (SS)

SS 目標

  • 戦略的達成目標の定義
  • 成長の機会の方向性の決定
  • 投資の優先度の設定
  • 成果の定義、有効性の把握
  • 戦略的資産の創出
  • 競争相手の識別
  • 結出したパフォーマンス提供による競争での優勢
  • 現在および将来の競争における優位を確実にする計画の策定

SS 活動

  • 市場の定義

    • 顧客に対する理解
    • 機会に対する理解
    • サービスの分類と視覚化

      • Figure(2) : サービス原型と顧客資産

        itil5.jpg (20.2 kB)

           U = 有用性(Utility)  A = 資産(Asset)
        

  • 提供内容の開発

  • 戦略的資産の開発

  • 実行の準備

    • 重要成功要因(CSF : Critical Success Factor)の定義
      • 事業の可能性の調査
      • 顧客のニーズとの同期
      • 拡大と成長
        • 既存契約の延長
        • 要求の増加
        • 補完的サービスによる拡大

SS 手法・技法・ツール

  • サービスの自動化
    • (そのために) サービスの分析と計測
  • サービス・インターフェース
    • サービスと技術の組み合わせ
      • 技術なし型:ex) コンサルティング・サービス
      • 技術支援型:ex) 顧客が搭乗手続きを行うための端末を使用する空港の担当者
      • 技術促進型:(顧客とプロバイダの両者が同一の技術にアクセスできる)
      • 技術媒介型:ex) サービスデスクを介して情報を受け取る顧客
      • 技術生成型:ex) 現金自動預払機(ATM):セルフサービス
  • サービス戦略のツール
    • シミュレーション
    • 分析モデル化
  • 投資利益率
    • ビジネス・ケース
    • プログラム実施前ROI
      • ふるい分けによる決定(正味現在価値:NPV (Net Present Value) )*
      • 選好的決定(内部利益率:IRR (Internal Rate of Return) )
    • プログラム実施後ROI
  • サービス提供モデルと分析

サービスデザイン (SD)

SD 目標

  • 事業達成目標に貢献する
  • 可能な場合、時間短縮とコスト削減に貢献する
  • リスクを最小化または予防する
  • 現在および将来の市場ニーズへの対応に貢献する
  • ITサービスの有効性と効率性をアセスメントし、改善する
  • ITサービスに関する方針と標準の策定を支援する
  • ITサービスの品質に貢献する

SD 活動

  • 要件の策定
    • 要件の種類
  • データと情報の管理
    • 適用範囲
      • データ・ソースの管理
      • データと情報技術の管理
      • 情報プロセスの管理
      • データの標準と方針の管理
    • データ管理とサービス・ライフサイクル
      • 可用性によるデータの評価
      • 消失したデータの評価
      • ライフサイクルにおけるデータの評価
    • データの分類
      • 運用上のデータ
      • 戦術的データ
        • 管理情報システムから
      • 戦略的データ
        • 外部(市場)情報と比較した長期的な傾向
    • データのオーナ
      • データのCRUDを行える人の決定
      • セキュリティ・レベルの承認
      • 事業内容と用途の合意
    • データの完全性
      • 消失したデータの回復
      • データへのアクセス・コントロール
      • データのアーカイブに関する方針の実施
      • データの完全性の定期的なモニタリング
  • アプリケーション管理
    • 導入するための2つの選択的アプローチ
      • サービス開発ライフサイクル
      • アプリケーション保守
    • アプリケーション・フレームワークの識別
    • CASE(Computer Assisted/Aided Software Engineering)ツールの選定
    • アプリケーション開発
      • 課題
        • コーディング規約、管理チェックリスト、など
      • アウトプット

SD 手法・技法・ツール

  • 技術に関する考慮事項
    • 設計プロセスの高速化
    • 標準への準拠
    • プロトタイプとモデルの開発
    • さまざまざシナリオ(what if)の考慮
  • サービス・ライフサイクル各段階・全段階の支援
    • コストの管理
    • サービス・ポートフォリオとサービス・カタログの管理
    • 構成管理システムとサービス・ナレッジ管理システム
    • 一般的な活動
      • さまざまなIT資産間の関係の形式化
      • 役割と責任の定義
    • アプリケーション資産管理
    • データ/情報資産管理
    • ITインフラストラクチャ資産管理
    • スキル資産管理
  • サービス・マネジメントのツール評価に関する考慮事項
    • データ構造、データ処理、データ統合
    • 国際的な標準への準拠
    • 導入・利用・データ共有における柔軟性
    • サービスレベルのモニタリングのサポート

サービストランジション (ST)

ST 目標

  • 最終目標
    • 事業(顧客)の変更プロセスを支援する
    • 新規または変更されたサービスのパフォーマンスの差異および既知のエラーを削減する
    • サービスがサービス仕様の要件を確実に満たすようにする
  • 達成目標
    • 新規サービスを実現、計画、および管理するための必須の手段となる
    • すでに本番環境にあるサービスに対してインパクトを最小化させる
    • 顧客満足度を改善し、サービスと相互技術の適切な使用を促進する

ST 活動

  • 移行計画の立案およびサポート
  • 変更管理
    • 変更の計画立案と管理
    • リリースの計画立案
    • 変更の許可
    • 復旧計画の策定
    • インパクト・アセスメント
    • コニュニケーション・報告・継続的改善
  • サービス資産管理および構成管理(SACM:Service Asset and Configuration Management)
    • 管理と計画立案
    • 構成識別
    • 構成管理(コントロール
    • ステータスの説明と報告
    • 検証と監査
  • リリース管理および展開管理
    • 計画立案
    • 構築、テスト、展開の準備
    • 構築とテスト
    • サービスのテストとパイロット
    • 展開の計画立案と準備
    • 移転、展開、または廃止
    • 展開の検証
    • 初期のサポート(ELS:Early Life Support)
    • レビューとクローズ
  • サービスの妥当性確認およびテスト
    • 妥当性確認およびテストの管理
    • テストの計画立案と設計
    • テスト計画とテスト設計の検証
    • テスト環境の準備
    • テストの実施
    • 終了基準とレポートの評価
    • クリーンアップとクローズ
  • 評価
    • 評価の計画立案
    • 予測されたパフォーマンスの評価
    • 実際のパフォーマンスの評価
    • リスク管理
  • ナレッジ管理
    • ナレッジ管理の戦略
    • ナレッジの継承
    • データと情報の管理
    • SKMS(Service Knowledge Manamement System)の使用

ST 手法・技法・ツール

  • ITサービスマネジメントシステム
    • CMDBやその他のツールを統合し、関連づける統合能力を与える企業のフレームワーク
    • システム管理ツール、ネットワーク管理ツール、およびアプリケーション管理ツール
    • サービス・ダッシュボードおよびレポート作成ツール
  • 各種のITSM技術とツール
    • サービス・ナレッジ管理ツール
    • コラボレーション・ツール、コンテンツ管理システム、ワークフロー・ツール
    • データ・マイニング、データ抽出、データ変換のためのツール
    • 測定と報告のためのツール
    • テスト(管理)ツール
    • 公開ツール
    • リリースと展開の技術
  • 変更管理・構成管理・リリース管理で用いる特殊ツール
    • 構成管理
    • バージョン・コントロールのツール
    • 文書管理システム
    • 設計ツール
    • 配布ツールとインストールツール
    • 構築ツールと展開ツール

サービスオペレーション (SO)

SO 目標

  • 指定された合意レベルで、事業のユーザと顧客にサービスを提供し管理するために必要な活動とプロセスを調整し、実現すること

SO 活動

  • イベント管理
    • イベントの発生・通知・検出・フィルタリング
    • イベントの重要度付け(分類)・相関付け
    • 対応の選択
    • 処置のアセスメント
    • イベントのクローズ
  • インシデント管理
    • 識別 -> 記録/ログ -> カテゴリ化
    • 優先度付け -> 初期診断 -> エスカレーション
    • 調査と診断 -> 解決と回復
    • クローズ
  • 問題管理
    • 検出 -> 記録 ->カテゴリ化
    • 優先度付け -> 調査と診断 -> ワークアラウンドの判断
    • 既知のエラーの識別
    • 解決策の発見
    • クローズ
    • 重要な問題のレビュー
    • 開発環境における間違い
  • アクセス管理
    • アクセスの要求 -> 検証
    • 権限の付与
    • IDステータスのモニタリング
    • アクセスの記録と追跡
    • 権限の削除または制限
  • IT運用
    • コンソール管理/運用統制
    • ジョブ・スケジューリング
    • バックアップとリストア
  • その他の運用上の活動
    • サーバ管理とサーバのサポート
      • オペレーティングシステムのサポート
      • すべての構成アイテムのライセンス管理
      • 3次サポート
      • 調達の助言
      • システムのセキュリティ
      • 仮想サーバの定義と管理
      • キャパシティとパフォーマンス
    • ネットワーク管理
    • 保存とアーカイブ
    • データベース管理作業
    • ディレクトリ・サービス管理
    • デスクトップ・サポート
    • ミドルウェア管理
    • インターネット/ウェブ管理
    • 施設管理とデータセンタ管理
    • 情報セキュリティ管理とサービスオペレーション
      • 監視と報告
      • 技術支援
      • 運用上のセキュリティ管理
      • 審査と調査
      • レーニングと意識付け
    • 運用活動の改善
      • 手動タスクの自動化
      • 一時的な活動のレビュー、または活動のレビュー
      • 運用監査
      • インシデント管理と問題管理の活用
      • コミュニケーション、教育とトレーニン

SO 手法・技法・ツール

  • 統合されたITサービスマネジメント技術(またはツールセット)
  • セルフヘルプ(ウェブ・インターフェースによるFAQなど)
  • ワークフローやプロセス管理エンジン
  • 統合された構成管理システム
  • 検出/展開/使用許諾に関する技術
  • リモート・コントロール
  • 診断ユーティリティ
  • レポート作成機能
  • ダッシュボード
  • ビジネス・サービスマネジメントとの統合

継続的サービス改善 (CSI)

CSI 活動

  • 点検
    • プロセスの結果を点検する
    • 顧客満足度を調査する
    • プロセスの成熟度をアセスメントする
    • スタッフが内部の指針に従っているか点検する
    • 測定データを分析し、それらをSLAに設定されている最終目標と比較する
  • 報告
    • ライフサイクルの全段階について改善を提案する
    • 既存の最終目標の妥当性を検討する
  • 改善
    • サービスの品質、効率性、有効性、および顧客満足度を向上する活動を導入する
    • 改善活動に適切な品質管理方法を使用する

CSI手法・技法・ツール

  • 導入のレビュー
  • アセスメント
    • レベル
      • プロセスのみ
      • 人材、プロセス、技術
      • 包括アセスメント
    • 段階
      • 計画立案段階
      • 導入段階(実施)
      • 測定段階(点検)
  • ベンチマーク
  • バランス・スコアカード
  • ギャップ分析
  • SWOT分析
    • 強み(Strength)、弱み(Weakness)、機会(Opportunity)、脅威(Threat) に注目
  • Rummler-Brache スイムレーン図
  • ツール
    • ITサービスマネジメント・スイート
    • イベント管理
    • システム管理とネットワーク管理
    • インシデント解決と問題解決の自動化
    • サービス要求と履行(サービス・カタログとワークフロー)
    • パフォーマンス管理
    • アプリケーションとサービスのパフォーマンス・モニタリング
    • 統計分析ツール
    • ソフトウェア・バージョン・コントロール/ソフトウェア構成管理
    • ソフトウェア・テスト管理
    • セキュリティ管理
    • プロジェクト管理とポートフォリオ管理
    • 財務管理
    • ビジネス・インテリジェンス/報告

Appendix

  • Figure(4):インシデント・ライフサイクルにおける改善の機会

    p55.png (939.4 kB)

  • Figure(5):リスク管理の一般的なフレームワーク

    p59.png (1.3 MB)

  • MoSCoW分析

    • M:MUST・・・持たなければならない
    • S:SHOULD・・・持つことが推奨される
    • C:COULD・・・持つことが可能である
    • W:WOULD・・・今回は持たないが、将来的に持ちたい

  • CMMIの成熟度モデル

    • 連続表現の能力レベル

      • 不完全な
      • 実施された
      • 管理された(能力レベル1)
      • 定義された(能力レベル2)
      • 定量的に管理された(能力レベル3)
      • 最適化している(能力レベル4)
    • 段階表現

      • 1.初期
      • 2.管理された
      • 3.定義された
      • 4.定量的に管理された
      • 5.最適化している

  • 規格 ISO/IEC 20000

(参加Blog)JAWS DAYS 2019

About me

  • これから Corporate Operation Engineer をやっていく、元 DevOps Engineer。
  • 現在の関心事は SalesforceISMS(経営に役立つよう、ITSMに発展・統合させたい・・・)、あとは「いい社内SE」って、何か。

Thoughts

  • コミュニティの活力が凄い。
    • これだけ熱くて、世の中がよくなっていかないはずがない、と感じた。
  • CISSPセミナー等でも聞いていたのですが、これからはパブリッククラウドが選択肢の第一になっていく。間違いなく。
    • いろいろな情報・技術をうまく活用できるエンジニアを目指していかないとなあ、と会社員の地位を失った(自ら破棄したのですが)身の上で改めて思った。
  • 相互アウトプットを、もっとやっていこう、と感じた。
    • 15:10〜16:00 #jd2019_c の速報を出したのですが、かなりの反響で、登壇者の方にフォローしてもらうに至った。
    • その方のタイムラインを少し眺めたところ、これまでに自分が知らなかった世界が開けたという大きな成果を得た。

Visited

業務ハッカー を目指していくというコンセプトでセッションを選択

10:10 - 11:00 #jd2019_g

[Ops] 子育てで覚える AWS organizations 〜ITエンジニア英才教育〜
https://jawsdays2019.jaws-ug.jp/session/1600/

(資料とコメントなど)

11:10 - 12:00 #jd2019_f

IT系コミュニティ大集合! Community Friendship Showcaseやります!
https://jawsdays2019.jaws-ug.jp/archives/2546/

(コミュニティ一覧とその他情報など)

time name speaker Twitter HashTag
11:15 エンジニアの登壇を応援する会 ariakiさん #engineers_lt
4/30 20:00 - 予定の「平成最後の日を祝うLT大会&パーティ」にも期待
(近日参加募集開始予定、トノコト)
11:18 TERAKOYAFORCE 板垣さん #TERAKOYAFORCE #salesforce #SFDC
11:21 umekitaforce 山田さん #umekitaforce #salesforce
関西のSalesforceコミュニティ
11:24 Netadashi Meetup 蒋さん #netadashi
11:27 CMC_Meetup 小島さん #CMC_Meetup
11:30 JBUG 西馬さん #JBUG
Japan Backlog User Group
11:33 SORACOM User Group itoxさん (すみませんWiFiの電波弱いのに難儀しててメモ残ってない...)
11:36 ssmjp 洲崎さん #ssmjp
一応インフラ・運用がメインテーマ
アウトプットしないのは知的な便秘
11:39 JP_Stripes 岩崎さん #JP_Stripes
11:42 Ansibleユーザー会 佐藤学さん #ansiblejp
11:45 SIerIoTLT 杉田さん #iotlt
11:48 RPA Community 井手さん #RPALT

12:15 - 13:00 Lunch Sessions

(メモ・・・正直、Lunchしながらだとまともに聞いてられなかった)

  • FalconNest

  • Sumo Logic

    • Outlier機能
      • 外れ値を除外
    • Predict
      • 予測
    • 収集方法3つ
  • Black Duck

13:10 - 14:00 ハイブリッドクラウド #jd2019_g

みていたのとは違うかもだがAWSから出ている資料

14:10〜15:00 #jd2019_c

[Supporter Session] 運用自動化支援するクラウドサービス「SIOS Coati」をサーバレスアークテクチャで全部作り直して、本当に良かった話
https://jawsdays2019.jaws-ug.jp/session/1274/

Link to My 聴講メモ [Qrunch](登壇資料は見つからず)

15:10〜16:00 #jd2019_c

[働き方] エンジニアが正しく成長するための、脱昭和&平成ワークスタイル
https://jawsdays2019.jaws-ug.jp/session/1743/

Link to My 聴講メモ [Qrunch](登壇資料は見つからず)

16:10〜17:00 #jd2019_e

[AWS本] 我々はこうして「AWS本」を書いた! 〜十人十色〜
https://jawsdays2019.jaws-ug.jp/session/2259/

勝手ながら、 @kondoyuko さんのメモをもってまとめにしてしまいます...

  • (1つ前のセッションメモで完全燃焼気味でした。。ぼーっと聞いてただけ。。)

17:20 - 19:30 [懇親会]

  • 途中から、前職の仲間+その仲間とで、日本酒を呑みながら少し話しに行きました(Twitterに流れてた集合写真、すごいなあ、と後で思ったり)。 ※妻子にナイショにできる程度の時間的長さで。
  • ひょっこり勉強会に行って、知り合いがいるって、ありがたいもんだなあ、と思いました。
  • 個人事業主にもなったので、ビジネス的な話ができたりすると、いいなあ。(まあ、あせらずに、かな。)

Others

References

  • 早くも資料のまとめが出ていたので紐づけてしまう

  • 事前に下調べしていくセッションを並べていた My note (予定、ズレましたけどね)

(参加メモ)第10回 PostgreSQLアンカンファレンス@東京

  • 開催概要
    • 開催日時:2/2(土)午後(13時半~17時半くらい)
    • 規模感:20分セッション×10本×3部屋(予定)
    • 参加者:50~60名くらいを想定
    • プログラム:当日調整します
  • 場所

  • Twitter HashTag

Thoughts

  • アンカンファレンス が初めてだったのだが、とても楽しい形式と感じた。
    • 今後はガシガシ参加していきたい。
    • この形式に向いた会場。トイレがロック解錠必要なのには面食らったが。
      • 飲み物の自販機、選択肢が多彩でかなりの低価格。
  • 貴重な事例が聞けた。とてもありがたい。
    • DB運用でのあれこれが、ふんだんに。

プログラム

20190202_program.jpg (940.5 kB)

勉強会前の時間が空いたのでアンカンファレンスの様子

RDBアンチパターン

14:20 - 14:40 (曽根さん)
(資料は見つけたら追加)

  • フラグの闇
  • データベースの迷宮
  • 転んだ後のバックアップ
  • タイムゾーンの業
  • まとめ
    • DBの問題は忘れた頃に
    • サーバーの問題は休日に
    • アプリケーションの問題は納期前に
    • 脆弱性の発見は連休中に

勉強会のほうの様子

PostgreSQLの暗号化について

14:40 - 15:20 (坂田さん) [^1]

  • データベースを安全に扱う

    • データベースの脅威(への対策)
      • 暗号化
      • アクセス制御
      • 監査
    • 暗号化と鍵管理
      • 常にセットで考える必要がある
  • データベース暗号化

    • 方法
      • PostgreSQLが提供
      • ベンダが提供(PowerGresなど)
      • OSが提供
    • ツール
      • pgcrypto
      • TDE for PG
        • エグゼキューター層
      • PowerGres Plus
        • ストレージマネージャ層
      • dm-crypt
        • OS層
  • 驚異のモデル化

    • DB内からの不正参照
    • DB外からの不正参照
    • 物理的な不正取得
  • 暗号化が必要なデータだけを暗号化するべき

  • 暗号化性能の組み合わせ

    • オーバーヘッドをもっとも小さくする組み合わせ
      • 範囲:列
      • 処理層:OS
  • アプリケーションでの対応

    • 難しさ
      • ...
    • 透過的データ暗号化
      • TDE for PG
      • PowerGres Plus
  • 暗号化と鍵管理

    • 鍵管理についての要件
      • PCI-DSS
        • 3.5 鍵管理について
        • 3.6.5 取り換えについて
    • 鍵管理システム(KMS)
    • 鍵ローテーションを考慮して暗号化方式を選択する
  • PostgreSQL セキュリティ機能強化

    • 9.5
      • ...
    • 9.6
      • ...
    • ・・・(書くのが追いつかない・・・)

PostgreSQL 11 解体新書

15:25 - 16:05 (曽根さん) [^1]

  • (4000円くらいの話をタダで聞ける)
  • 目玉の新機能
    • パーティションの強化
      • 10で入って、11で圧倒的強化
      • 3種類
        • レンジ
          • 1月,2月,3月などの範囲で分ける
        • リスト
          • 東京,大阪,名古屋のような
        • ハッシュ
          • 指定したKey(int)÷テーブルの余りで分散する
      • 性能強化
        • その1
        • その2
        • その3
    • パラレルクエリの強化
      • 11で追加された対象
        • Parallel Hash Join (9.6からより強化)
        • CREATE TABLE AS SELECT
          • データ移行で移すときに役立つ
        • CREATE MATERIALIZED VIEW
        • UNION ALL によるAPPEND
        • SELECT INTO
        • CREATE INDEX
      • 多くの読み込みは並列化できる
        • 書き込みはまだ未対応
      • 基本的にはVer.upするだけで速くなる
    • SQLの拡張
      • INDEX ONLY SCAN の強化
      • INCLUDE句の追加
        • INDEXに参照用の列を指定
      • Window関数の強化
        • EXCLUDE句
    • 嬉しいユースケース
      • パーティション同士の結合
      • スキャンが多い
      • ・・・
      • ALTERの際にDEFAULT NULLではないカラムの追加が高速に!
    • PostgreSQL 11 の罠
      • ・・・
      • JIT compile はまず導入されただけ
      • ストアドプロシージャに過度の期待をしない
      • 非互換の変更
      • RDSなどDBaaSに来るにはまだ時間がかかる
  • その他の新機能
    • JITコンパイルの導入
    • ストアドプロシージャの導入
      • ストアドファンクション(戻り値必須)はあった
      • テストデータ作るときに便利
    • レプリケーションの強化

皆さんのクソクエリ体験談

16:40 - 17:20 (カピバラおじさん さん?)

  • フレームワークのメンテナンスご苦労話

    • CodeIgniter
      • (date - 2 week) <= time を実現するときの苦労
        • トリガーを駆使した
      • MySQL は式インデックスがない
    • O/Rマッパーをどうやってチューニング?
      • 使わない
      • View を駆使
  • 10000カラムのテーブル

    • 最大 1600 カラムでは?
  • Memo

    • オンラインDDL
      • Aurola
        • 投げられる
      • MySQL 5.7
        • 投げられない
    • 「抽選で1名」をどう実装?
    • ElasticSerach は手繰れるけどBigQueryは手繰れない
    • RDBに苦手なことはRDBにさせない

アンカンファレンスから聞こえてきたのをメモなど

その他

  • WiFi は用意していく必要があるようだ
    • 今回自分は持参したが、問い合わせTweetしていた人がいた
    • 登壇者はケーブルも!
  • 実はちょっとした話題を Twitter でふっかけてみた https://twitter.com/sogaoh/status/1091601465313918976 20190202_myQuestion.png (47.4 kB)

    • これをきっかけに、 @soudai1025 さんがたまたま隣だったので少し話ができた。
      • RDBMSは、予測ができない。AIでも入れていかないと・・・と、文字通り壮大なことを。
    • 初めまして、だった
    • スケール大きいな、と思った

Note

[^1] : Twitter で教えてもらったのですが、PostgreSQL Conference Japan 2018 (2018-11-22) での資料のようだったので挿入しました