https://conhumi.net/ Recent content on Con_Humi の WEBサイト Hugo -- gohugo.io ja-jp Sat, 07 Dec 2024 00:00:00 +0900 https://conhumi.net/posts/2024-12-07-managing_maintenance_manual_of_a_certain_team/ Sat, 07 Dec 2024 00:00:00 +0900 https://conhumi.net/posts/2024-12-07-managing_maintenance_manual_of_a_certain_team/ とあるチームのメンテナンス手順書の管理の話 TL;DR 世の中には「メンテナンス手順書」って言うやつがあるよ とあるチームでは GitLab を使って 「メンテナンス手順書」を管理しているよ 個人的には GitLab を使ったメンテナンス手順書の管理は便利だと思うよ はじめに こんにちは。短い育児休業が終わり会社に復帰しました。 妻が継続で育休を取ってくれているおかげで、何とか仕事も進められています。ありがたい事です。 また、会社復帰に際してもスムーズに業務に戻れるよういろいろと配慮いただいたチームの皆様にも感謝です。ありがとうございます。 会社復帰して仕事を進める中での気づきのまとめとして、本稿ではとあるチームで行われているメンテナンス手順書の管理の方法をご紹介します。 「メンテナンス手順書」 とは？ ご存知の通り、ITシステムには「運用」というやつが多少を問わず必ずあります。 「運用」というやつには、「保守」や「メンテナンス」と言われる作業（以下「メンテナンス作業」）が多少を問わず存在します。 これは一般的にはシステムに変更を加えるものであり、軽重はあるもののリスクを伴うものとなっています。 多くの「運用チーム」ではメンテナンス作業のリスクをマネジメントするために、メンテナンス作業に際して「手順書」を作成し、 複数名のレビュー・確認や承認を経て作業を実施するような運用を行っているのではないかと思います。 本稿における「メンテナンス手順書」はそのようなメンテナンス作業のための手順書の事を指すものとします。 とあるチームの「メンテナンス手順書」に求められる事 「メンテナンス手順書」と言った時にイメージされるものは、IT業界に身を置く人の中でも職種や業種によって異なるのではないでしょうか。 本稿で紹介する「とあるチーム」は、クラウドサービスを活用してITシステムを自ら開発・運用しているチームを想定します。 メンテナンスの立案・手順作成・レビュー・リハーサル・承認・実施をすべてチーム内＋チームが属する組織の管理職で行っています。 注意：環境が異なるチーム（例えばメンテナンス手順書を作成するチームと実施するチームが異なるような場合）では、「とあるチーム」に求められる以外の要件が沢山ある場合もあるでしょう。 この「とあるチーム」のメンテナンス手順書には以下のようなものが含まれます。 メンテナンスの概要 目的や変更要旨 メンテナンス日時 メンテナンス手順の実績 過去実績や検証結果 メンテナンス手順 メンテナンスの前提条件 実施手順 事後手順や切り戻し手順も含む 上記内容が管理職のレビューを経て承認されている事 「メンテナンス手順書の管理」に求められること メンテナンス手順書のライフサイクル とあるチームでは、先述の「メンテナンス手順書」は以下のようなライフサイクルをたどります。（2,3 は前後・繰り返しの場合もある） 作成 リハーサル・修正 レビュー・修正 承認 実施 多くのIT組織において、各ステップの軽重・前後はあれど似たようなステップをたどるのではないかと思います。 それぞれのステップに求められる管理の要件は以下のようなものです。 「1. 作成」の管理要件 このステップでは特に求められている管理の要件はありません。 強いて言うならば、作成という作業そのものがやりやすい事が求められるでしょう。 「2. リハーサル・修正」の管理要件 このステップでは、手順書に起こした変更手順を開発環境や検証環境に適用し、本番メンテナンスのリハーサルを行います。 Tips：本番環境とリハーサルに用いる環境で何らかの差分がある場合（原則差分が無いことが望ましいが現実は難しい）はその差分に留意してリハーサルを行いましょう。 リハーサルの結果を次のステップ（3.レビュー）で参照できるように記録しておく必要があります。 また、リハーサルの最中に手順に間違いや不足が見つかった場合には、1のステップで作成した手順を修正する必要があります。 リハーサルにあたっては手順の見やすさ、修正に際しては修正作業のしやすさが求められます。 「3. レビュー・修正」の管理要件 このステップでは、メンバーや管理職にメンテナンス手順をレビューしてもらい、必要に応じて指摘・修正のキャッチボールが行われます。 レビュー・修正のしやすさ、改変内容の分かりやすさが求められます。 レビュワーにとっては、メンテナンス手順が見やすく表示され、気になった個所に簡単に指摘や質問のコメントを入れることが出来ると良いでしょう。 修正側にとっては、指摘の場所と内容が分かりやすいと修正がしやすいでしょう。 また、指摘に対してどのように修正を加えたのかが明確に分かると再レビューもしやすいでしょう。 「4. 承認」の管理要件 レビュー・修正 の手順で指摘事項をすべてクリアした手順を最終的に管理職が承認します。これによってメンテナンスの実施に進むことができます。 このステップでは、承認の証跡が明示できることが求められます。 組織によっては、承認者が何名も居て順番に承認を貰う事が求められることもあるでしょう。 また、管理職でないチームメンバーも承認フローに加わる事もあるでしょう。 「5. https://conhumi.net/posts/2024-09-28-migrate_blog/ Sat, 28 Sep 2024 10:25:28 +0900 https://conhumi.net/posts/2024-09-28-migrate_blog/ ブログを Cloudflare Pages に移行した話 TL;DR ブログを GCP + Cloudflare -> Cloudflare Pages に移行した ついでに Hugo のテンプレートも Gokarna に変えた Cloudflare 便利ぽ はじめに ８月末に長女が誕生し、今は育児休業をもらっています。 新生児期間（誕生から４週間）は妻と互いに一定程度のまとまった睡眠時間を確保するために、夜間は自分が/朝方から午前中は妻が育児を担当する分担を試しています。 （母体は母乳で胸が張るなど長い時間寝るのも大変という事情もあるようですが、枠を確保するというのも大事かなと…） 夜間の育児は、最低３時間に１回の おむつ交換 授乳（粉ミルクなので１度与えたら２時間以上は間隔を開ける） 寝かしつける といった内容で、全てスムーズに進めば １時間程度の所要時間となり、次のお世話まで何もなければ ２時間程度のまとまった時間が得られました。 この時間を使って、放置しているブログのネタを作ろうと考えました。 ブログの移行 以前、GitHub のコンテンツを Circle CI で GCS にアップロードして Cloudflare で配信するブログを作成しました。 月日が経ち、今は Cloudflare 中に Pages という機能が追加され、 Cloudflare の中だけで静的コンテンツの配信ができるようになっていました。 今回はこのサービスにブログサービスを移行しようと考えました。 https://zenn.dev/rivine/articles/2023-06-23-deploy-hugo-to-cloudflare-pages 上記ポストを参考に作業を進めました。ありがとうございます！ といっても特にやることはなく、Hugo でビルドできる状態のブログレポジトリを Cloudflare Pages に登録するだけでページを表示することができました。びっくりです。 （GitHub Pages とかもそんな感じなんでしょうか…？） Hugo のテンプレート変更 ついでに Hugo のテンプレートを Gokarna に変更してみました。 テンプレートのカスタマイズもやってみたいところです。 DNS のレジストラの変更 この機会に DNS のレジストラを お名前. https://conhumi.net/posts/2018-12-03-about_this/ Sun, 02 Dec 2018 12:04:56 +0000 https://conhumi.net/posts/2018-12-03-about_this/ 他社調査の名目で自分のブログを移築した話 これは FJCT Advent Calendar 2018 の3日目の記事です。 2日目は @hunter9x のElasticsearchのQueryが遅い時のトラブルシューティング でした。 4日めは @o108minmin さんの 2018年度新人技術研修の取り組みについて 話です。 こんにちは。FJCT でエンジニアをしている こんふみ です。 本記事では、普段の仕事ではなく、個人のブログを移築した話をしたいと思います。 TL;DR ブログを移転しました GCS と Cloudflare を使って、Hugo でビルドした静的WEBサイトを配信しています。 はじめに 毎年この時期は、アドベントカレンダーに参加するは良いもののネタが全然思いつかず悩んでいるわけです。 そもそも振り返ってみると、たまの休日にパソコンの前に座っていろいろ試行錯誤をしたとしてもブログなどに残す習慣が無いので忘れがち。前回やったことを調べなおすから先に進まないのでモチベーションが上がらず、休日はサボリ気味になるという負のループを断ち切るべく、ブログそのものをエンジニアリングの対象にしてみようという思いつきからこの記事はスタートしています。 （その思いつきが妥当なのかについては諸説あると思うので、突っ込まないであげてください） 移行計画 思い立ったが吉日ということで、移行後の青写真を描いておきます。 もともとは はてなブログ を利用しており、以前のブログは http://con-humi.hatenablog.com/ でした。 全然更新してないですね… 移行後のブログの要件は下記の通りとします。 Markdown で記事を書ける 独自ドメインでやる GitHub でコンテンツを管理する 以前 hugo を使ってブログを作ろうとしたことがあるので、ブログは hugo を使って作成し、 静的WEBサイトとして公開することとします。 ブログを公開するインフラはどうするかですが、冬はスノーボードに行かなければならない（義務感）なので お金は接続したいところ。 GCP さんには永久無料枠があるのを知っていたので、 GCP の永久無料枠を中心にインフラを検討します。 インフラの検討 コンテンツ置き場はおそらく GCS が 5GB 無料 なので当分大丈夫。 ドメインは10年分を買っているのに遊ばせているやつがあるので 実質無料 。 とりあえず SSL 化ができれば良いなと思っていろいろ調べていたところ、Cloudflare を使うと 無料で SSL 化ができそうなのに加えてコンテンツのキャッシュをしてくれるのでストレージへの アクセスも減ってくれそうなので、Cloudflare を使ってみることにします。