障害電話受け1番になった時に使える三つの心得

これは何

システムに障害が起こった時に電話が一番にかかってくるようになった人のための心得。具体的な障害対応手順ではなくて、元気にSREエンジニアとして生き残っていくための心得。

心得

1. 本当の優先事項は何かを考える

仕事の電話がかかってきた。(仮に)今は奥さんの誕生日食事会の途中だ。さあ電話に出て対応をするか? そういう時には対応をしてはいけません。他の人に任せましょう。ほっておけば2番目の人が電話を受けてくれます。 人生で重要なことの優先順位をつけましょう。電話がかかってきたら必ず仕事、なんてことはやってはいけません。そういう風に考えていると24時間いつでもかかってくる電話を所持していると精神が持ちません。気をつけましょう。 エンジニアとしても人としても長生きしましょう。 (補足:待機人員として拘束時間になっているならちゃんと出ましょう。しかし特に決まりもなく電話を持たされている場合には法的には何も拘束力がないと理解しています)

2. 最初にやることを意識する

まずは他の人も呼びましょう。 あまりにも軽微な障害なら一人で対応しても良いですが、すぐに問題原因が特定できない可能性があるもの、影響範囲が狭くないものの場合にはチームメンバーが気がつけるようにSlackで@channelしましょう。躊躇なく。 その目的としては以下のような人員を増やす目的があります

  • 問題原因特定のための人員
  • 原因特定後、手作業が発生した時に対応する手として
  • 影響システムや社内一次報告、関係会社などに連絡する連絡人員として
  • SREの知見は少なくてもユーザ目線で障害発生や復旧を確認できる動作確認人員として

なんにせよチームメンバならやれることはあるはずなので人を集めましょう。 上にはいろいろ理由は書きましたが、一人で対応するとテンパったりミスをしたりするのでオブザーバでもいてもらった方が良いです。

3. 障害対応は実況しよう

やったことは生のコンソールログを含めてSlackに貼っておこう。他のチームの状況なども可能なかぎり一つのチャンネルに集める。これの目的は以下のもの

  • 途中から対応に参加した人が状況を把握できる
  • 手分けして対応をしている場合に他の人の状況が把握できる
  • ミスや考え違いをしていたら他の人が気がつくことができる
  • 振り返りに使うことができる(後で見て情報ないと本当に困るので、やってみると効力がわかるはず)

実際にやったことだけでなく、障害原因の予想や、対応方針、ふわっとした違和感なども投げましょう。少しでも情報を表に出してみんなで考えることが大切です。書くことで自分の考えも整理されます。

終わりに

これらは電話をもらって頑張って死にそうになっている同期や後輩を見て考えたことです。

長生きしましょう。 ストレスためすぎているなと思ったら電話をおいて海にでも出かけるのも良いです。この投稿で言いたいことはこれがほとんで全てです。

障害電話受け1番になった時に使える三つの心得

これは何

システムに障害が起こった時に電話が一番にかかってくるようになった人のための心得。具体的な障害対応手順ではなくて、元気にSREエンジニアとして生き残っていくための心得。

心得

1. 本当の優先事項は何かを考える

仕事の電話がかかってきた。(仮に)今は奥さんの誕生日食事会の途中だ。さあ電話に出て対応をするか? そういう時には対応をしてはいけません。他の人に任せましょう。ほっておけば2番目の人が電話を受けてくれます。 人生で重要なことの優先順位をつけましょう。電話がかかってきたら必ず仕事、なんてことはやってはいけません。そういう風に考えていると24時間いつでもかかってくる電話を所持していると精神が持ちません。気をつけましょう。 エンジニアとしても人としても長生きしましょう。 (補足:待機人員として拘束時間になっているならちゃんと出ましょう。しかし特に決まりもなく電話を持たされている場合には法的には何も拘束力がないと理解しています)

2. 最初にやることを意識する

まずは他の人も呼びましょう。 あまりにも軽微な障害なら一人で対応しても良いですが、すぐに問題原因が特定できない可能性があるもの、影響範囲が狭くないものの場合にはチームメンバーが気がつけるようにSlackで@channelしましょう。躊躇なく。 その目的としては以下のような人員を増やす目的があります

  • 問題原因特定のための人員
  • 原因特定後、手作業が発生した時に対応する手として
  • 影響システムや社内一次報告、関係会社などに連絡する連絡人員として
  • SREの知見は少なくてもユーザ目線で障害発生や復旧を確認できる動作確認人員として

なんにせよチームメンバならやれることはあるはずなので人を集めましょう。 上にはいろいろ理由は書きましたが、一人で対応するとテンパったりミスをしたりするのでオブザーバでもいてもらった方が良いです。

3. 障害対応は実況しよう

やったことは生のコンソールログを含めてSlackに貼っておこう。他のチームの状況なども可能なかぎり一つのチャンネルに集める。これの目的は以下のもの

  • 途中から対応に参加した人が状況を把握できる
  • 手分けして対応をしている場合に他の人の状況が把握できる
  • ミスや考え違いをしていたら他の人が気がつくことができる
  • 振り返りに使うことができる(後で見て情報ないと本当に困るので、やってみると効力がわかるはず)

実際にやったことだけでなく、障害原因の予想や、対応方針、ふわっとした違和感なども投げましょう。少しでも情報を表に出してみんなで考えることが大切です。書くことで自分の考えも整理されます。

終わりに

長生きしましょう。 ストレスためすぎているなと思ったら電話をおいて海にでも出かけるのも良いです。この投稿で言いたいことはこれがほとんで全てです。

応用情報技術者試験を受けたので記録しておく

これは何

2017年10月にIPA応用情報技術者試験を受けました。12月合格発表で、結果が出た(合格した)ので、考えたことを記録しておく。

結果は?

点数は午前75、午後68ですれすれというほどでもないけどなんとも言えないところ。とはいえ、資格試験はボーダを超えるのが重要なので目標通りではあるのでOK。

応用情報って何

IPAが言ってる7段階のレベルの3に当たるもの。そろそろきちんとエンジニアとしてやっていくかな〜と考えているような人が受けるレベル。 午前試験と午後試験で分かれている。午前試験の開始が(特に私の所属する企業の)エンジニアの起床時間と比べて早いのが特徴的。 詳しいところ気になる方はググる感じでよろしくお願いします。

なぜ受けたか

  • 大学が化学系で、情報系出ていないのでコンプレックスがある
  • 受かると会社で一時金が出る
  • 幅広い知識も業界内の専門外の人と話す時に重要と思った
  • 経産省の調査で、諸外国含めたIT人材のレベルとお給金、的な資料を読んだ。だいたい自分のレベルとお給料の市場相場が一致しているのだなと気がついて、知識ベースアップのために受けてみることにした。(また、米国水準だと同じレベルだとお給金もうちょっと良さそうなので英語もぼちぼちやる) 参考資料: http://www.meti.go.jp/policy/it_policy/jinzai/27FY_report.html http://www.meti.go.jp/policy/it_policy/jinzai/27FY/ITjinzai_global.pdf

対策は?

前提知識(試験前のレベル)

午前試験

過去問見てみると業務で見たような単語が多い。過去問道場で雑にやってみると午前試験が無勉強で4割くらい取れる感じだった。最初のテキスト半分くらい読み終わった終わった段階で午前試験の過去問5割くらいだった。

午後試験

午後試験は10分野のうち4分野選択するのだが、私はセキュリティ、アーキテクチャ、ネットワークが無勉強で5〜10割くらいでばらつきあるが平均で合格点取れそうだが、あと1分野はどれも5割切りそうなのでどれとるか迷うレベル。

勉強時間は

多分30時間くらい。移動時間にやっていたのが多いので測定不能だがだいたいこれくらいだろう。平日の移動時間に10分くらいの細切れ学習時間の積み重ねと、土日のどちらかの1〜2時間くらいをカフェでのんびり参考書読む感じだった。 おそらく午前試験に20時間くらい。午後試験に10時間いかないくらい。

学習内容

午前試験

  • 参考書を読む「キタミ式イラストIT塾 応用情報技術者 平成29年度」。この参考書はわかりやすくてよかった。他の参考書も買ったが、なぜそうなるのかとか書いておらず「公式」とか書かれていたのでゴミ箱に捨てた(比喩)。まずは本の7割くらい苦手分野を中心にざっくり読んだ。
  • 過去問道場というサイトで電車内でちまちま過去問やる。過去問題解きつつ、わからなかったら参考書やググる。気になったものがあったら好奇心のままに調べる(ただし移動時間10分くらいの長さだけ。基本深くは潜らない)。

午後試験

だいたい1週間前(本格的には前々日)から午後試験対策をした。参考書は2週間前くらいに中古の安いやつ買った。「2014 応用情報技術者午後問題の重点対策 (午後問題対策シリーズ)」。この本も解説が詳しくてなかなかよかった。正直あんまり読んでないけど。版は古いがどうせ資格試験なんて大して内容変わらないだろうと思っての安いやつ。試験では新しい話題も出てきていたが、正直ベースがあればやはり解けるので新しいのにこだわらなくてもいいなと思った。業界内にいる人は普段から最新技術もなんとなく話を聞いているだろうし。 セキュリティ、ネットワーク、アーキテクチャは傾向だけさらっと見て、あと一分野どうするか決めるためにいろいろ解いてみた。

どれにする? 午後試験の問題は当日選べる。一夜漬けするならどれだ。

  • マネージメント: 雰囲気で半分取れるが安定しない。博打なので無し。
  • 情報システム開発: 過去問見る感じだといろんなフロー的なのとか出てくる。雰囲気でとけるが、しっくりこないのでとりあえず無し。他に選択肢がなければやる。
  • アルゴリズム: 一つの大問に平均20〜30分が標準だが、問題によって40分くらい時間をかければ7割取れそう。できるようになれば硬いが、一夜漬けは無理そう。他の大問が早く終わって当日楽そうだったら(時間をかければ解けそうだったら)選ぶ
  • データベース: 正規化とか設計の方はなんか本読んだことあるのでわかるが、普段ゴリゴリにSQL書いていないので副問い合わせとかなんか空欄にされるとなんかよくわからん。1週間ちゃんと対策すれば7割硬そうだがとりあえず無し

当日ぱっと見、情報システム開発の分野がテストケースの話で点数そこそこ取れそうだったので選択。なんとかなった。

辛かったこと

  • これが一番難しいとされている。会場が家に近かったのでなんとかなった。
  • 会場が寒い。雨の日だったこともあり午前試験で凍えてしまった。次の日から風邪引いた。ちゃんと厚着していくこと。

やってよかったか?

  • 幅広いなんとなくの知識はついた。情報卒コンプレックスは多少解放されたが、次はさらに高度試験受けないと。完全解消にはやはり情報系大学院いくのが良いか。
  • 正直午後試験はもうちょっと時間かけてやった方が身になった。知っている知識でごり押しした。
  • BNF記法とか身近だけどあんまり意識していないものに触れられたのでよかった。
  • 一番よかったことは、勉強習慣がついたこと。受験時代にやったようなことを思い出したので最近プライベートでもいろいろ自発的に学ぶようになった。

ansible vmware_guest_find モジュールを用いたVM存在確認と後続タスクの制御

これは何

ansibleによるVMwareVMインスタンス管理の話。 VMインスタンスをコマンド一つで作成して初期設定ができるようにAnsibleで管理している。すでに存在するVMについては、うっかりRebootしたりNW Restartなどが走らないように存在チェックをしてそれらのタスクをスキップしたい。

vmware_guest シリーズの module について

  • vmware_guest module
    • VMを作るためのモジュール。ansible version 2.2 より使用可能。
  • vmware_guest_find module
    • VMが存在するディレクトリを教えてくれる。ansible version 2.4 より使用可能(なので、最初v2.3を使っていて数分ハマった)。
    • 今回の話題。
  • vmware_guest_facts module
    • VMの設定値を取得できる
    • これはVMのリソース設定が正しく設定できているかの確認に使える(assetsモジュールと組み合わせる)。

コードとハマリどころ

コード 

# vmware_guest_findはすでにVMがいれば戻り値としてvm_folder.foldersにVMがいるディレクトリが入る(ここで、vm_folderはregisterで定義した変数)。居ない場合もしくは認証がうまく行かなかったなどの場合にはエラーになり、vm_folder.msgにその原因が書かれる。
# 後続のタスクは、VMがまだ居ない場合にのみ実行したい。
- name: check vm exists on vsphere
  vmware_guest_find:
    hostname: VMホスト名
    username: ユーザ名
    password: パスワード
    name: VMインスタンス名
    datacenter: データセンタ
  register: vm_folder
  ignore_errors: yes  # とりあえず ignore_errorsにしたけどfailed_whenで制御した方が綺麗だったかも。そのうちなおすかも。

- name: create and setting vm
  block:
    - name: create vm  # ここら辺の中身は今回は略
      include: create_vm.yml
      tags: create_vm
    - name: setting vm
      include: setting_vm.yml
      tags: setting_vm
  when: (not ("folders" in vm_folder)) and (vm_folder.msg | regex_search("Unable to find folders for VM"))

解説

vmware_guest_find module の戻り値。 Debugで見てみる。

- name: debug
  debug:
    msg: "{{ vm_folder }}"

VMがいるとき

    "msg": {
        "changed": false,
        "failed": false,
        "folders": [   # これが帰ってくるのが特徴的
            "/vm/hoge/development"
        ]
    }
}

VMがいないとき

TASK [../ex_roles/vsphere_vmmaker : debug] ******************************************************
ok: [test-vmmaker] => {
    "msg": {
        "changed": false,
        "failed": true,
        "msg": "Unable to find folders for VM test-vmmaker"
    }  # msgが帰ってくる。他の原因でmodule実行が落ちると他のmsgが帰ってくるのでそれを利用する。
}
  • find と言う名前がついているので戻り値にBooleanが帰ってくるかと思ったらVM Folderが帰ってくるのだった
  • ない時にはFalseが帰ってくるかと思ったらErrorになってしまうのだった
  • 単に「find module実行が落ちたらVM設定する」にしてしまうと、なんらかの拍子にmoduleが落ちると意図せずcreate vm, setting vmが走ってしまって嫌だったので、それを念入りに回避するためにmsgを見ている
    • もっと綺麗にかければよかったけど安全策をとった形
    • find moduleはまだ安定していないので後方互換を取らないかもしれない、と言う注意文言があったのでmsgは変わるかもしれない(This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface. と書かれていた)
    • msgがマッチしている時にだけ設定が走るので、msg文言が変わっても実行しないという安全側に倒れるので良い

コメント

  • ちょっと美しくないが、とりあえず動くVM作成と、事故らない動きを実現した話。
  • 社内ユーザの要望の声が大きければ enable_modify などのフラグを指定した時にはVMリソース設定や細かい設定を変えさせるのはやっても良いかもしれない。

インフラエンジニアがバックエンド書けるようになるために paiza と progate を使っている感想

これは何

バックエンド開発ができるようになるためにお家でPaizaやProgateを使ってPHPRailsをお勉強している話。

目次

背景

私はメインの専門領域はWebインフラエンジニア(サーバエンジニア)なわけですが、そろそろアプリケーションコードもそこそこ書けるレベルじゃ無いと仕事がしづらいなと思ってきた。 だいたいコードの関連箇所の概要教えてもらったらコードを読み書きできるけども、自分一人で完全に問題箇所特定して修正してチューニングする、みたいなことがちょっとしにくい気がする(感覚的なもので、まだ何が知識として足りないか分かってないのでふわっとしている)

どう学ぶか?

会社で

一番いいのは会社で仕事としてアプリケーションコードを書くのが良い。とはいえ、私のメインで関わっているシステムはレガシーすぎるので「綺麗なコード」とか「良いアーキテクチャ」というのを学ぶのがなかなか難しい。本とか読めばある程度分かるのだろうが、ベースである程度読み書きして体に染み込んで無いと辛いところはある。
インフラ領域においてはやはりレガシーなところに放り込まれたが、3年という潤沢な時間をかけて試行錯誤しながら(なんとか動くくそコードを量産しながら)なんとか良い状態とは何かというのがなんとなく分かったつもりである。同じようにアプリケーションについて試行錯誤し続けるのも無駄な気がした。

自分で

となると、まずは独自で学習するしかない。ある程度分かってきたらそこそこ新しいシステムでアプリケーションコードを書かせてもらうように交渉するのが良さそう。 というわけで教材を探すわけである。とは言っても能動的に探したというよりも、問題意識を持っていたらTwitterで流れてきたのが目についてそれに飛びついた形。 さて、前置きが長くなったがPaizaとProgateについて。

Paiza

主観的な内容

競技プログラミングを学ぶためっぽい感じの内容だった。お題が出されてそれを実装する。主に実装速度(と高レベルになると実行速度)が見られる感じ。 実装速度を求められるのは新鮮で、就職活動をするときに自分の実力を知るためにFizzBuzzを時間計って頑張って書いたのを思い出した(10分以内にかけないくそプログラマもいる、と書かれている記事を読んだ後にやって7分くらいでできたので安堵したのを覚えている)。

選んだ言語

仕事でPHP関係が多いので、まずは最低限PHPコード読むのに苦労しない程度学ぼうと思ってPHPを選ぶ。

内容とレベル感

ざっくりやってみて、Bレベルまでは解けるのは分かった。このレベルだと、想定回答時間内に終わらないことも多いが、最終的になんとか回答できる感じ。Cレベルは普通にふわっと書いて終わるレベル。 Bで苦労するものがまあまああるので、Aは無理そう。
しばらく頑張ればBがスイスイ解けるようになるだろうと思ったが、今そうなりたいかと言われるとちょっと違うと思ったのでここで終わり。

自分とマッチしているか

ところで、Paizaは求人と紐付いているだが、きている求人があわなさそうなのが多いのでちょっとないかなという感じ。提案されるお給料にコーダーとしてのお値段を実感した。コードだけ書きたいわけでもなし、ここを極めるのは自分の進む違う感じがして一旦終わり。

Progate

主観的内容

Railsの教材を選んだ。そのせいか、コードを書くというより、アプリケーションを実際に作ってみるというのに重きを置いている感じ。ちょうど何か自分で全部作りたいなと思っていた時期だったので、マッチした。他のRubyの教材とかは雰囲気違うかも。

内容とレベル感

内容としては、「一気に全てを学びましょう」ではなくて、RailsだったらRailsの機能に焦点を当てているところが特徴的。当然、見た目それっぽいアプリケーションを作るためにはHTMLやCSSの知識も欠かせないわけだが、そこらへんは「ここにもう書いてあるのでコピペして該当箇所に貼ってね」という感じで、本当に基礎のところを知っていればスムーズに学びを進められる。綺麗なWebサイトつくるために後でそのコースも取ろうかな、と思わせる作り方なのがよかった。 今の所レベル26までやって、微妙に完全脳死ではできない感じでちょうど良い。

自分とマッチしているか

今の所結構良さそう。Railsはアプリケーションを高速で作るのに適していると聞くし、後で自分のプロダクト作るときに使えそう。裏の細かい技術的なことはインフラやってる経験から後からまあまあ調べられると思うし「だいたいこんなんで作れるだろう」というレベルまでいければ御の字。しばらく頑張ってみたい。

おまけ

N予備校

ちょっとだけやってみた。環境構築からしっかり学ばせるというコンセプトが強い。そこらへんは個人的には間に合っているので別にこれじゃなくていいかなというところ。本当のエンジニア初心者には結構良いかもしれない。関係ないが、世界史とかの講義を聞いていると「なるほどそういうことだったのか」という学びが大きいので、そういう一般常識的なものを学ぶのにむしろ使いやすそう。しかし講義は1時間とか長いのでもうちょっと細切れの方が楽だなあと思いつつ、ちゃんと流れで理解するためにはそれくらいのまとまりは必要だろうなどと思ったりする。

まとめ

昔は本使ってRails触ってみて続かなかった。Webサービス使うとうまく進捗や理解を管理してくれるので楽で楽しくやれる。微妙にお金はかかるけど専門書買うのより安かったりして最近麻痺してお金をいろいろ突っ込んでいる。

DNS切り替えを伴う環境移行のハマりどころと気をつけポイント

これは何

大きくサーバ群をリプレイスする時に考えるべきこと、詰まりどころをまとめておきたい。

目次

事前リソース見積もりについて

データ取得と方針

  • 継続的にデータを取得しておく
    • ピーク時平均値とスパイクするポイントが重要
  • 負荷について
    • 新環境は負荷をかけても耐えられるか。まずは旧環境と同様の負荷
    • 今後の伸びを考慮した負荷

特に気にすべき負荷

ストレージ
  • ディスクサイズ
    • 負荷とは少し違うかも
    • 今後の伸びを考慮した割当を行う。オンライン後から追加できるならある程度攻めても良い。補足:気軽に増やしたり出来ない物理サーバで5年でリプレイスするなら、5年後に70%になる程度にするとよいかもしれない
  • IOPS ランダムアクセスに対する指標である。ブロックサイズが大きいものについてはIOPSが思ったより出ないこともある。その場合はスループットが重要
ネットワーク
  • 新旧環境をまたぐトラフィックが発生する場合には特に注意が必要
  • レイテンシ
    • サービスでどの程度まで許容できるのか
    • DBなのかcacheなのかでも違う
  • トラフィック
    • LB、ルータ、スイッチ、ケーブルのキャパ
    • 特に環境間のルータがボトルネックになるし、影響範囲も大きい

疎通問題について

  • 同じIPセグメントなら問題は起こりにくい
  • 違うセグメントに新サーバを立てるなら既存サーバから/に疎通ができるか
    • L7レイヤまで確認するのが望ましい
  • 必要に応じてルーティング設定をいれる
    • 細かく /24に対してのroutingなどを入れていっても良いが、セキュリティ的な問題がない or リスクが飲めるなら /8 でいれるのもあり

LB・FWの設定について

  • Global IPは割り当てられているか
  • LB設定はすべてのドメインとパスに対して入っているか
  • SSL証明書は設定されているか
    • 鍵と証明書は行方不明になりがち
    • 鍵の置き場(秘匿情報置き場)をあらかじめ決めておくと良い
  • IP直うちでアクセスした時にどういう動きをさせるのか決めておく
    • 503を返していいのか、何からのデフォルトサーバに到達させて200にするか、など
  • 社内外からアクセスできるか
    • 特に社内だけ空いていて、社外からアクセスできないということがないか?
  • 必要に応じてACL設定を行う、もしくは抜いておく

DNS設定切り替えについて

  • ここまでは準備だが、DNS切り替えをした時が本当の切り替えタイミング。重要なので慎重に行う
  • 他の関係者に切り替え時間と目的が分かるように周知する
    • 社内
    • 社外関係サービス(あれば)
  • 設定担当者と動作確認担当者の連絡手段を決めておく
    • いつでもいいのか、連絡が必要なのか
    • メンションなどが必要なのかどうか
    • 同期をとって行うか
  • TTL設定
    • あらかじめ小さくしておく
    • 長いとなかなか反映しない
    • 問題が起こった時に切り戻しに時間がかかる
  • 問題発生時
    • すぐに切り戻す
    • 根本原因究明はその後

ansible のダウンロード処理のリトライ(と既存コードの書き換えスクリプト)

これは何

playbook の自動テストで各種パッケージダウンロードの処理がたまに落ちていた。コードの問題ではないところで落ちてjenkinsが赤くなると嫌なので出来るだけ通るようにしたい。 リトライ処理をいれて問題の緩和を図りたい。 微妙に詰まったのでメモを残しておく。

参考文献

コード解説

- name: download nginx source
  become: no
  get_url:
    url: "http://nginx.org/download/nginx-{{ NGINX_VERSION }}.tar.gz"
    dest: "/usr/local/src"
  register: download_result
  until: download_result|succeeded
  retries: 3
  delay: 5

until, reties はセットで書く必要がある。untilの記述がなければretiesは1になる。 untilでの判定をするためにregisterで変数にタスク実行結果を入れておく。

おまけ

既存コードの書き換えのためのスクリプト

沢山の場所を書き換えないといけないのでperlスクリプトを使った。

grep -r "get_url:" | awk -F':' '{print $1}' | sort | uniq | xargs perl -i -0pe 's/(get_url:(.*\n)+?)^\s*$/\1  register: download_result\n  until: download_result|succeeded\n  retries: 3\n  delay: 5\n/m'

以下スクリプト解説のようなメモ書きのような。

基本的にyamlのブロックごとに改行を挟んでいるので、それを用いる。 オプション修飾子mは対象文字列が複数行である場合に使う。 以下のような構造のyamlになっていた場合に、^\s*$で空行までのマッチになる。 ここで(.*\n)+?に?をつけているのは最短一致のためで、これをつけないと最長一致になってしまって空行1までではなくて、いけるところまでいったところ(この場合は空行2)までマッチするので注意が必要。

- name: download nginx source
  become: no
  get_url:
    url: "http://nginx.org/download/nginx-{{ NGINX_VERSION }}.tar.gz"
    dest: "/usr/local/src" 
(空行1)
- name: hoge
  piyo: fuga
(空行2)
- name: hoge
  piyo: fuga

便利ツール紹介

ところで、正規表現を最初からコマンドラインで書くのもありなのだけど、あまりにも辛いのでGUIツールを使うのがよい。以下のサイトが最高なのでみんな使うべき。 https://regex101.com/