nwiizo

Dockerfile のベストプラクティスを考える機会はありますが皆さんの意見も聞きたい。今回は噂の便利ツール、Open Interpreterのような外部コマンドをどんどん実行して環境を作り変えるようなタイプのツールの場合にはDockerはとても有用です。そのようなツールを利用する時のDockerfile について考えていきます。リポジトリは以下になります。github.comGitHub Actionsとの連携GitHub Actionsは、CI/CD（継続的インテグレーションと継続的デリバリー）をGithub 上に簡単に実装できるツールです。今回は、trivy.ymlとdocker-publishを利用することで、セキュリティのスキャンとDockerイメージの自動公開が可能です。github.comtrivy.ymlの利用trivy.ymlは、Trivyという脆弱性スキャナーをGitHub Actionsで動かすための設定ファイルです。この設定を利用することで、Dockerイメージに存在するセキュリティの脆弱性を自動で検出できます。docker-publishの追加docker-publishは、DockerイメージをDocker Hubや他のレジストリに自動で公開するためのGitHub Actionsのワークフローです。これにより、新しいバージョンのOpen Interpreterがリリースされた際に、手動でイメージをビルド・プッシュする手間が省けます。Renovate.jsonの利用renovate.jsonは、依存関係を自動で更新する設定ファイルですが、これを使うとOpen Interpreterが依存しているライブラリやパッケージが新しくなったときに、自動でプルリクエストが作られるんです。そうすることで、いつも最新の状態を保てるわけですから、セキュリティリスクも減らせます。さらに、Pythonのパッケージも自動で更新したい場合は、requirements.txtを使って設定しておくと便利です。これにより、Pythonの依存パッケージも最新の状態を維持できるようになります。github.comDockerfileを書く際の注意点私は以下のようなDockerfileを書きましたその際に以下のようなポイントを意識して書いたので参考にしてください。github.com軽量なベースイメージの使用不必要なパッケージを含まない軽量なベースイメージを使用することで、ビルド時間とイメージサイズを削減できます。FROM python:3.11キャッシュの最適化RUNコマンドを効率的に配置することで、Dockerキャッシュを最適化できます。RUN apt-get update && \  apt-get upgrade -y && \  apt-get install -y --no-install-recommends git && \  rm -rf /var/lib/apt/lists/*不必要なパッケージの削除--no-install-recommendsオプションを使用して、不必要なパッケージをインストールしないようにします。  apt-get install -y --no-install-recommends git && \作業ディレクトリの設定WORKDIRを設定することで、その後のコマンドの実行ディレクトリを明示的に指定できます。WORKDIR /root機密情報はコンテナイメージに絶対に埋め込まない社内で有識者へ投げたら機密情報をビルドイメージに追加することを指摘されたので運用時の手癖やミスで何処かのレイヤーに不用意に埋め込まないようにしたgithub.comまとめDockerでOpen Interpreterを運用する際には他にもいろいろ考えるべきことがあると思うので皆さんと議論したいのでIssue待ってます。

Open InterpreterのDockerfile を書いたのでTipsとか

「ツールよりもプロンプトのほうが、隙間がなくて効率的なのでは？」... ああ、面倒なブログになるな、とおれは直感した。はじめに近年、プルリクエスト（PR）の管理が開発フローにおいてますます重要な位置を占めるようになっています。ただし、PRをより良く作る作業は往々にして煩雑で手間がかかりがちです。その解決策として、Codium AIによって開発されたPR-Agentが脚光を浴びています。このAIソフトウェアは、OpenAIのGPT-4技術を基盤にしており、単にOpenAIのAPIキーを設定するだけで、既存のCI/CDパイプラインに簡単にインテグレーションできます。github.comPR-Agentの主な機能PR-Agentは、様々なPR関連作業を自動化するための多機能なオープンソースプロジェクトです。具体的には、以下のような機能群を提供しています。/describe: タイトル、種類、要約、コードの詳細説明、およびラベルを自動で作成するためのPR（プルリクエスト）説明自動生成機能。/review: PRの主題、種類、関連テスト、セキュリティ問題、評価スコア、その他のフィードバックを調整可能に提供する自動レビュー機能。/ask ...: PRに関するフリーテキスト質問に回答する質問応答機能。/improve: PRを改善するためのコミット可能なコード提案を行うコード改善提案機能。/update_changelog: PRの変更内容に基づき、CHANGELOG.mdファイルを自動で更新する更新履歴自動更新機能。PR-AgentはOpenAIのAPIキーを設定するだけでCI環境に簡単に組み込め、開発者が効率的なPR作成と管理を行えるよう支援します。このツールはGPT-4を用いて高精度なソースコード解析とレビューを自動で行い、開発者が重要なポイントに集中できるようにします。さらに、「PR Compression Strategy」と呼ばれる独自のアルゴリズムによって、大規模なPRでも重要なファイルと主要な言語のコードブロックに焦点を当てた効率的なレビューが可能です。それ以外にもさまざまな設定により、PR-AgentはPR作成とレビューのプロセスを自動化し、効率化する強力なツールであり、大規模プロジェクトにおいてもスムーズかつ効率的なレビュープロセスを実現します。これらをどのように動作させればよいのかはUsage guideを読んでみてください。PR-Agent のPromptPR Compression Strategyにより、送信するファイルの戦略が定められています。その設定に加えて、pr-agent/pr_agent/settings/ ディレクトリには、TOML形式でプルリクエスト（PR）のレビュープロンプトのテンプレートが含まれています。具体的には、pr_review_promptはpr_reviewer_prompts.toml ファイルに定義されており、これがPRのレビュープロセスにおける基本的な指示とフォーマットを規定しています。この構成により、PRレビューが一貫性を持ち、効率的に行えるよう設計されています。pr_reviewer_prompts.toml 解説pr_reviewer_prompts.tomlは、Pull Request（PR）レビューに関する設定と指示を定義する設定ファイルです。この設定ファイルは、PRレビューを自動化する際に利用されます。pr_review_prompt セクションsystemこの設定は、レビュワーがどのような役割を果たすべきかを定義しています。具体的なPR Diffの入力例も提供され、新しく追加されたコード（+で始まる行）に焦点を当てるよう指示されています。system="You are PR-Reviewer, a language model designed to review git pull requests. ..."num_code_suggestionsコード提案が必要な場合、その数や重要度についての指示がこの部分に記載されています。{%- if num_code_suggestions > 0 %}- Provide up to {{ num_code_suggestions }} code suggestions. ...{%- endif %}extra_instructionsパラメータで、追加的な指示や設定を行うために使用されます。この項目は主に以下のような用途で利用されることが多いです。{%- if extra_instructions %}Extra instructions from the user:{{ extra_instructions }}{% endif %}YAMLスキーマこの部分で、PRレビュワーが出力するレビュー結果のYAMLフォーマットが定義されています。Main theme, PR summary, Type of PR, etc.これらは、PRに関する基本情報を整理するためのフィールドです。Main theme:  type: string  description: a short explanation of the PRScore, Relevant tests added, Insights from user's answer, etc.これらのフィールドは、PRに関する詳細な評価やテスト情報、ユーザーからのフィードバックに基づく評価を行います。Score:  type: int  description: Rate this PR on a scale of 0-100 ...General suggestions, Code feedback, Security concernsこれらのフィールドは、具体的なコード提案やセキュリティ上の懸念など、PRのコードに関する詳細なフィードバックを提供します。General suggestions:  type: string  description: General suggestions and feedback for the contributors ...user セクションこのセクションは、PR作成者から提供される情報（タイトル、ブランチ、説明文など）を取り込む場所です。user="PR Info:Title: '{{title}}'Branch: '{{branch}}'Description: '{{description}}' ..."この設定ファイルによって、PRレビューのプロセスが自動化され、一貫性を持つようになります。特定のプロジェクトやチームに特有の要件に応じて、これらの設定はカスタマイズ可能です。まとめpr_reviewer_prompts.tomlといった設定ファイルを読んで全体としてPRのフォーマットに忠実にプロンプトを作成していったのがわかりました。参考にしていきたいと思います。github.com参考PR-Agent を使って Pull Request をAIレビューしてみた。（日本語対応もしてみた）GitHub - Codium-ai/pr-agent: 🚀CodiumAI PR-Agent: An AI-Powered 🤖 Tool for Automated Pull Request Analysis, Feedback, Suggestions and More! 💻🔍

まずPR-AgentをPromptとします。

はじめに最近、ChatGPTからCustom instructions機能がリリースされました。Custom instructionsとは、ChatGPTの応答方法をより詳細に制御するカスタム命令を設定することができる機能です。ChatGPTの利用者にとって非常に便利な機能です。この機能により、ユーザーは特定の応答スタイルやフォーマットを要求することができるようになりました。これは、特定の業界や専門分野での使用など多岐にわたる用途に適応できるため、非常に有用です。めちゃくちゃ端的にかつ語弊を恐れずにいうと毎回、prompt を入力しなくてよくなるやつです。以前、公開したプロンプトに関するブログsyu-m-5151.hatenablog.comOpenAI CEOのSam Altman氏も、Custom instructionsのポストをしていましたので参考にしてみても良いかもしれません。damn i love custom instructions pic.twitter.com/su0BlttJF7— Sam Altman (@sama) 2023年7月22日  その上で私が利用してるものを公開します。What would you like ChatGPT to know about you to provide better responses?I'm a software developer and primarily use Golang. Depending on the application, I also utilize Shell Script, Terraform, and Ansible.I am a software developer and I like Cloud Native technologies such as Docker and Kubernetes.I like to develop, operate, and optimize systems.Technical advisor for several other companies.Please use Japanese.How would you like ChatGPT to respond?You are an AI programming assistant.Your response should be informative and logical.First, think STEP-BY-STEP, then describe your plan for what to build.Then output the code in a single code block.Keep your answers objective and concise, and use Markdown formatting.Be sure to include the name of the programming language at the start of the Markdown code block.Avoid enclosing your entire response in a triple backtick.また、 respondに信頼性に関する言及を求めていたのですが有益な情報が得られないので削除しておきました。まとめCustom instructions機能は、ChatGPTの応答をより細かく制御する強力なツールです。これにより、ユーザーは特定のニーズに合わせてモデルを調整することができ、より多様で効果的な結果を得ることが可能になります。この機能の導入により、ChatGPTはさらに多岐にわたる分野での応用が期待されます。この書籍はChatGPTによって達成された科学的な貢献や重要性を理解することができるのでオススメです。ChatGPTの頭の中 (ハヤカワ新書)作者:スティーヴン ウルフラム早川書房Amazonおすすめ記事honeshabri.hatenablog.com

ChatGPT: SREがCustom instructions機能を利用する

概要Cloud Operator Days Tokyo 2023 で SREからPlatform Engineerへの拡大 というテーマでの登壇を果たしました。オンデマンド配信なのでいずれ見れるようになると思います。今回のサブタイトルは【運用の新時代】とし、それにちなんでメインタイトルを考えました。資料の作成過程で、話したい内容がどんどんと増えてきてしまい、20分という限られた時間での発表が一番の課題となりました。内容の整理に際して、具体と抽象 ―世界が変わって見える知性のしくみ という本を参照し、大変役立ちました。具体と抽象作者:細谷 功dZERO（インプレス）Amazon資料このブログでは、Cloud Operator Days Tokyo 2023での登壇内容をまとめております。資料作成時に参照したさまざまな参考情報も掲載していますので、読者の皆様が別途情報を探す手間を省けるよう心掛けました。ぜひ、本ブログをご活用ください。文字多くて分かりにくいのは分かってます。脳内整理はできているのですが資料を読みやすくすると20分に何も収まらず...。 speakerdeck.com参考文献O’Reilly Japan – SRE サイトリライアビリティエンジニアリングあなたらしくSREO’Reilly Japan – サイトリライアビリティワークブックO’Reilly Japan – SREの探求SRE at Google: How to structure your SRE team | Google Cloud BlogレトロスペクティブガイドWhat Is Platform Engineering?Top Strategic Technology Trends for 2023: Platform EngineeringMaking the Business Case for a Dedicated Platform Engineering TeamSRE NEXTPlatform Engineering Meetupチームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計The History of DevOps ReportsEffective DevOpsオブザーバビリティ・エンジニアリングWebエンジニアのための監視システム実装ガイド

SREからPlatform Engineerへの拡大 というタイトルで登壇しました

github.comLunarVimユーザーとして、私はNeovimでcopilot.luaを頻繁に利用しています。しかし、マルチラインのサポートに関してはいくつかの課題がありました。もっというとどこかのタイミングでCopilotが一行ずつしかサジェストされなくなりました。この問題に対して、一部のコードを修正することで、この課題を解決する方法を見つけました。問題点Copilot.lua(Copilot.vimも同様に)の中のagent.jsには、マルチライン入力の停止点を示すコード h.stop=["\n"] が含まれています。この設定により、一部の場面でマルチラインサポートが期待通りに動作しないことがありました。解決方法私が採用した方法は、このh.stop=["\n"]をh.stop=["\n\n\n"]に変更することです。この小さな変更により、マルチラインのサポートが大幅に向上します。以下のコマンドを実行することで、この変更を簡単に適用することができます。MAC でのsed 利用なのでこのようなコマンドになります。各環境で合わせていただきたいです。sed -i '' 's/h\.stop=\["\\\\n"\]/h\.stop=\["\\\\n\\\\n\\\\n"\]/' ~/.local/share/lunarvim/site/pack/lazy/opt/copilot.lua/copilot/dist/agent.js変更が正しく適用されたかどうかを確認するには、以下のコマンドを実行します。grep -o '.\{30\}h.stop=\[.\{30\}' ~/.local/share/lunarvim/site/pack/lazy/opt/copilot.lua/copilot/dist/agent.js結果この変更を適用した後、マルチラインサポートが明らかに向上しました。興味があれば最初に紹介したIssue に動画が添付されていたのでご覧ください。LunarVimとCopilot.luaの組み合わせは非常に強力ですが、小さな調整によりさらに快適に使うことができます。このハックが他のユーザーにも役立つことを願っています。後日談この変更を適用した後でマルチラインサポートは向上したのですが一部条件ではまだ、vscodeのような挙動ができません。

2023年8月10日現在 でLunarVim と Copilot.lua でのマルチラインサポートの改善方法 

概要CloudNative Days Fukuoka 2023というイベントに『K8sGPT Deep Dive KubernetesクラスタのAI駆動型分析について』というタイトルで登壇しました。クラウドネイティブとAIを組み合わせることの深い洞察を共有することができ、私自身がエンジニアとして働くなかで、K8sGPTの最新の進化とその可能性について詳しく語る機会はなかなかなく、この経験を活かしていきたい。資料を作っている中で話したいことがどんどん増えていってめちゃくちゃ困った。また、その中でAIOpsについても触れることができ、非常に充実した時間でした。AIOpsはAIと運用管理の統合を指し、それによりIT運用の効率化や自動化が可能となります。その重要性と可能性を伝えることができたので良かった。登壇が終わった今でも、K8sGPTやAIOpsについてさらに知識を深め、クラウドネイティブの世界にどのように最適化された解決策を提供できるかについて考え続けています。参加者の皆さんからもたくさんのフィードバックを頂き、今後の研究や開発の参考になりました。私がこのプレゼンテーションのために読み込んだ複数の本の中で、特に皆さんにお勧めしたい一冊を挙げるとすれば、「大規模言語モデルは新たな知能か――ChatGPTが変えた世界」だと言えます。なぜなら、専門家でも初心者でも、難解な数学を使わずに重要な概念を理解できるように作られているからです。大規模言語モデルは新たな知能か　ＣｈａｔＧＰＴが変えた世界 (岩波科学ライブラリー)作者:岡野原 大輔岩波書店Amazon資料登壇資料になります。このブログの目的は参考資料をいちいち探さなくていいようにありますのでご活用ください。 speakerdeck.com参考文献公式ページ | K8sGPTGitHub | K8sGPTGitHub | K8sGPT OperatorDocs | K8sGPTOperator patternK8sGPT OperatorHow to Get Started With AIOpsPrompt Engineering Guideオブザーバビリティ・エンジニアリングKubernetes基盤を自律的に支えるController化の実装Tips / forkwell-202303-amsy810-k8sAutomation and Machine Learning with Site Reliability EngineeringTEMPLE: Six Pillars of ObservabilityAI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想 / DICOMO2022 6A-1大規模言語モデルは新たな知能か――ChatGPTが変えた世界 (岩波科学ライブラリー)ChatGPTの頭の中 (ハヤカワ新書)言語の本質　ことばはどう生まれ、進化したかAI vs. 教科書が読めない子どもたち【ITIL4公認】ITIL 4の基本 図解と実践

K8sGPT Deep Dive というタイトルで登壇しました #CNDF

概要AIの技術は目覚ましい進歩を遂げています。特に自然言語処理（NLP）の分野では、GPT-4のようなモデルが人間に近いレベルで文章を理解し、生成することができるようになりました。しかし、これらのモデルを日々の業務や作業にどのように活用すればよいのか、多くの人々がまだ手探りの状態です。一方、コマンドラインは、システム管理者やソフトウェア開発者にとって重要なツールです。コマンドラインからシステムの状態を調べたり、プログラムを実行したりするためには、これらで利用するコマンドの理解とそれらを十分に使いこなすことが必要です。netflixtechblog.comアフィリエイトでも何でもなく運用で利用するコマンドについてはLinuCなどもあるので教材を読むだけでもおすすめしたい。linuc.orgでは、AIがコマンドプロンプトの結果を理解し、それを人間がより理解しやすい形で説明することができたら、どうでしょうか？ここで、AICommandを紹介します。AICommandは、コマンドプロンプトの実行とその結果の解釈を統合したツールであり、AIの力を借りてコマンドプロンプトの結果を理解する新しい試みです。今回の記事では、このAICommandについて詳しく見ていきましょう。シェルコマンドの実行とその結果をOpenAIのGPTモデルに結果を送信し解説を要求するGo製CLIツールです。コマンドの処理状況も視覚的に表示します。 pic.twitter.com/5q6jqyWbsx— nwiizo (@nwiizo) 2023年7月18日  AICommandの紹介AICommandは、コマンドプロンプトの結果を人間が理解しやすい形に解釈するための新しいツールです。OpenAIの強力な自然言語処理モデルを使用して、コマンドラインから得られた情報を詳細に解析し、その結果を説明します。これにより、複雑なコマンドの実行結果も、非専門家でも簡単に理解できるようになります。github.comコマンドプロンプトは非常に強力で、システムの管理やデータの分析には欠かせないツールですが、その結果を正しく理解するには専門知識が必要で、学習コストが高いという課題がありました。しかし、AICommandを使えば、そのハードルが大きく下がります。たとえば、システムのログを確認するためのコマンドを実行した結果を、AIが解釈し、重要なポイントをハイライトしてくれます。さらに、その結果がどういう意味を持つのか、何が原因でそうなったのかといった情報も提供してくれます。このように、AICommandは、AIの能力を利用して、コマンドプロンプトの利用をより手軽で、より理解しやすいものに変えることを目指しています。ソフトウェア開発者やシステム管理者だけでなく、コマンドラインを利用するすべての人々にとって、新たな可能性を広げるツールとなることを目指します。option で日本語にも対応してます。 pic.twitter.com/AkEHh5syPx— nwiizo (@nwiizo) 2023年7月19日  Setup 🔧AICommandはGo言語で書かれているため、Goの開発環境が必要です。まず、Goがまだインストールされていない場合は、公式のインストールガイドに従ってGoをインストールしてください。Install aicommandGoがインストールされたら、次にAICommandをインストールします。go install github.com/nwiizo/aicommand@latestSet the your_api_keyAICommandはOpenAIのGPTモデルを使用しますので、OpenAIのAPIキーが必要となります。OpenAIのアカウントを持っていてAPIキーを取得済みの場合は、そのAPIキーを使用します。まだAPIキーを取得していない場合は、OpenAIの公式ドキュメントを参照してAPIキーを取得してください。APIキーを取得したら、そのキーを環境変数 OPENAI_API_KEYに設定します。設定方法は以下の通りです：export OPENAI_API_KEY=your_api_keyUsage ⏳コマンドの実行とその結果の解釈を行うには、次のように execute コマンドに続けて実行したいコマンドを引数として与えます。コマンドは(ダブル)クオーテーションで囲む必要があります。aicommand execute "your-shell-command"たとえば、ディレクトリの内容をリストする ls -la コマンドの結果を解釈させたい場合は、次のように実行します。aicommand execute "ls -la"すると、AICommandは ls -la コマンドを実行し、その結果を解釈して人間が理解しやすい形で説明します。また、解釈結果の言語を指定したい場合は、 --language または-lオプションを使用します。現在、英語（en）と日本語（ja）がサポートされています。デフォルトの言語は英語です。aicommand execute --language ja "ls -la"さらに、使用するGPTモデルを指定することも可能です。これは --model または -m オプションで指定します。デフォルトは gpt-3.5-turbo です。aicommand execute --model gpt-3.5-turbo "ls -la"これでAICommandの基本的な使用方法について説明しました。コマンドプロンプトの結果の解釈がこれまで以上に手軽になり、より深い理解が可能になります。AICommandの可能性🤖AICommandは、私たちが普段利用しているコマンドプロンプトをOpenAIのGPTモデルと組み合わせることで新たな可能性を生み出します。たとえば、複雑なコマンドを実行した結果の意味を理解することが困難な場合や、ログの解析、データ分析などで結果をより深く理解するための手助けとなります。また、様々なプログラムやスクリプトの実行結果を人間が理解できる形で説明してくれるため、デバッグやエラー解析の作業を効率化することが可能です。AICommandを利用すれば、テクニカルな知識がなくてもコマンドラインから得られる情報を理解しやすくなるかもしれません。結論🦾AICommandは、AIとCLI（Command Line Interface）の架け橋となるツールであり、この2つの強力なテクノロジーを組み合わせることで、未知の課題に対して新たな視点を提供します。さまざまなバックグラウンドを持つユーザーがコマンドラインから得られる情報をより容易に理解できるようになることで、これまで手が出せなかった問題に取り組む手助けをしてくれるでしょう。しかし、その一方で、AICommandはコマンドプロンプトの出力を人間が理解できる形で解釈するツールであるため、その解釈は絶対的な真実を表すものではありません。AICommandの解釈結果は参考の一つと考え、最終的な意思決定はユーザー自身の判断に任せるべきです。以上のことを念頭に置いて、AICommandを活用すれば、新たな視点からコマンドラインの世界を探索することが可能になるでしょう。ソフトウェア開発にChatGPTは使えるのか？――設計からコーディングまでAIの限界を探る作者:小野 哲技術評論社AmazonCloudNative Days Fukuoka 2023 にて登壇余談なのですが"k8sgpt Deep Dive: KubernetesクラスタのAI駆動型分析について” というタイトルで登壇を行います。event.cloudnativedays.jp参考AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想 / DICOMO2022 6A-1AICommand GitHubリポジトリOpenAIsashabaranov/go-openai

CLIの実行結果を正しく理解することを促すツールを作成しました。

概要開発生産性Conferenceというイベントに『Cloud Native の作法 - 成熟度モデルを活用したCloud Nativeへの道筋』というタイトルで登壇しました。生産性に関するイベントなんですけど現場のエンジニアをやっている僕には開発生産性について語ることってあんまりないようなーって思いながら最近、成熟度モデルについて調べていたのでこのタイトルにしました。途中で開発生産性について語るのを諦めてガッツリ資料を作り直しましたので生暖かく見守ってください。あと、ちょっと前に書籍を送って頂きましたが📖 Twitter での告知を忘れていたのでしておきます。読んだ感想としては入門書では決してないですが成熟度モデルでいうとレベル2の段階では読んでほしいと思う書籍になります。また、豊富にドキュメントへのリンクが貼ってあるのでKubernetesという荒野に道を示す地図になると思います(この文章はChatGPTではなく俺が生成した)。Kubernetesの知識地図 —— 現場での基礎から本番運用まで作者:青山 真也,小竹 智士,長谷川 誠,川部 勝也,岩井 佑樹,杉浦 智基技術評論社Amazon資料登壇資料になります。このブログの目的は参考資料をいちいち探さなくていいようにありますのでご活用ください。 speakerdeck.com参考文献Cloud Native Maturity ModelCloud Native TransformationDesign Patterns for Cloud Native ApplicationsIntro to the Cloud Native Maturity Model - Danielle Cook, Simon Forster, Robbie Glenn & John FormanSRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本: Googleが実践している新DevOps方法論SRE サイトリライアビリティエンジニアリングサイトリライアビリティワークブックCloud Native成熟度モデルがWeb公開されましたWhat's the Difference Between DevOps and SRE?Solving Reliability Fears with Site Reliability EngineeringReliability When Everything Is a Platform: Why You Need to SRE Your CustomersThe History of DevOps ReportsEffective DevOpsPlatform Engineeringへの招待Platform Team と 社内政治 〜 出でよ、Platform Champion 〜 / Platform Team and Internal Politics - Platform Engineering Meetup #2Platform Engineering at MercariEMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシッププロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで正しいものを正しくつくる　プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先についてエンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

成熟度モデルを活用したCloud Nativeへの道筋 という副題で登壇します #開発生産性con_findy

🍡 前回の記事syu-m-5151.hatenablog.com🐶 はじめにこんにちは。株式会社スリーシェイク Sreake 事業部に所属している@nwiizo です。Sreake事業部は技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。事業部にはさまざまな背景を持つSREの専門家が多く在籍してます。しかし、そのSREの専門家達とは案件が一緒にならなかったり、能動的に質問をしなければSREに関する意見や知見を聞けませんでした。SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践オライリージャパンAmazonそんな、課題がある中で半年前に各案件で得た知見や経験を各メンバーで出し合える会がもっと(社内で技術共有会はあるため)あると良いと思いました。そこで社内チャットで有志を募り 『輪読会について考える会』を行いました。社内チャットで運営を募ると一瞬で集まったので良い組織だと思いました。※『輪読会の各話』の議事録が見れるTOPページです。🐵 各メンバーの感想と今後のアクションsugoude途中からの参加でしたが、楽しく役立つ輪読会でした。特に16章17章はDBREに関する内容でしたので当事者意識を持って参加し、有意義な時間になりました。個人的には、途中からの参加でしたので、SREの探求を再演してもらえたら嬉しいです。hash_gen選定理由としてみんなSRE本は読んでるだろうという点もあったと思いますが、様々なケースと向き合ってきたSreake事業がある3-shakeだからこそSREの探求を輪読する価値があったと思いました。様々な事例に対して我々の場合はどうやって提案していけばよいかという会話が多かったことが印象に残っています。日々のアウトプットでも技術フォーカスの内容に加えて具体的な経験例を社内に積極的にフィードバックしていくことでこのいい習慣を続けていけたらと思っています。SatohJohn入社してまもなくというのも有り、そこまでSREの用語に対して詳しくなかったため、この本を読むことで、どうしてそれらの用語が必要なのかが深掘りできたきがしました。また、個人的にGoogle CloudのDevOpsの試験を受けることが有り、その際にもこの本での話題が役に立ちました。今後アプリケーション開発にSREの考えを入れられるようにするのに、ちょうどよい粒度だったと感じております。tozastationインターンの方が参加したタイミングだけ出れたのでそのエピソードで...! Sreake 事業部だけでなく、他事業部も巻き込んで開催していたのが素敵だなと思いました。Sreake の仕事を知ってもらうであったり、他事業部にも SRE を取り込んでもらうなどさまざまな意見交換が生まれる場だったじゃないかと思います。インターンの方も声を上げてくれたのがさらに良かったです！次のテーマも応援してます！nnaka2992DBRE兼SRE見習いとしてSRE活動をしている自分にとっては、データベース以外でのSREの取り組みを技術・ヒューマンスキル両方の面から学べる本でした。弊社のような不特定多数の組織に対するSREの導入サポートを行う企業では、それぞれの組織に合わせたSREの適用が必要となります。様々なSRE実践例を扱う本書籍は自分の知見を深める面でも、SREとしての引き出しを増やす面でも素晴らしい書籍でした。今後はあくまでこの書籍はある組織での最適解としてリファレンスしながら、それぞれの組織で最適となるSREの探求を続けられればと思います。とあるメンバーすごい有意義な時間でした。Sreake内で自分は人数も組織も大きな組織でどうやって既存の組織にSREを導入するか？を考えているので、様々なプラクティスを知れたのは良い体験でした。輪読で学んだことをお客様に話すと「なるほど！」と言ってもらえることも多々ありました。🐦 まとめ今回の読書会は、新しい知識共有のコミュニティーを作り上げながら実施しました。毎週1回、定められた時間にオンラインに集まり、担当者が1章ずつ読みまとめ、それについて話し合うのです。そして、その議論の過程をドキュメントに記録し、印象に残った部分をいつでも見返せるように保存しておけます。感想はもちろん、一人一人異なりますが、それぞれが課題や組織に向かって解決策を考えていくのがとても面白かったです。その結果、同じ本を読んでいても、それぞれ異なるアクションを考え出すことができました。このようなコミュニティを活用した議論と輪読により、活発な意見交換をしながら特殊なミームが発生したり楽しく読書を進めることができました。これからも、このスタイルの読書会は続けていく予定です。皆さんも、一緒に働くメンバーと読書会を試してみてはいかがでしょうか？新たな知識共有の体験、その刺激を味わってほしいです。弊社の採用サイトも載せておきますjobs-3-shake.com

SREの専門家が集まったチームで『SREの探求』の社内輪読会を完遂しました。

概要ModuleはTerraformの複数のリソースをまとめて再利用可能な単位として扱うことができます。Moduleを使うことで複雑なリソース構成を抽象化し、システムの構造の把握やリソース構成の再利用が可能になり、読みやすさや可読性が向上し、修正箇所が単一になるなどのメリットがあります。ただし、理解には初期コストが必要です。Moduleの設計では、1つの機能を持つように小さくシンプルに保つことが重要で、それが難しい場合は大抵複雑と言えます。また、公式のModuleを利用することで、自身で定義やドキュメントの整備、メンテナンスの手間を省きつつ、プロジェクトを超えて共通認識として扱えるため、Module理解のコストが減ります。しかし、どのタイミングでModuleに組み込むかの正解は、個々のプロジェクトの特性や開発チームの状況により大いに変わるでしょう。絶えず試行錯誤を繰り返しながら個々のプロジェクトごとに最適な解を見つけることが求められます。このブログではそれらの話の前にTerraform Modulesについて利用方法をまとめてみました。概要Module を利用するmoduleの使い方moduleの入力ローカルをうまく利用するmoduleの出力module を使ったときの失敗についてバージョン状態の差分は可能な限り小さくすべきアップグレードは自動されるべきファイルパスインラインブロックいい感じのデフォルトの変数最後に参考Module を利用するシステムを構築するにあたって開発、検証、本番環境をそれぞれ用意することが多いですが、Terraformを環境ごと（例：開発環境、ステージング環境、本番環境）にシンプルなWebサーバーの構成を例にしてModuleを使わないときと使ったときの構成を比較してみましょう。Terraform Configuration|--- Development Environment|   |--- VM Instances (Web servers)|   |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)|   |--- Load Balancer (Balance traffic among VM instances)|   |--- Storage Bucket (Store static content)|--- Staging Environment|   |--- VM Instances (Web servers)|   |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)|   |--- Load Balancer (Balance traffic among VM instances)|   |--- Storage Bucket (Store static content)|--- Production Environment|   |--- VM Instances (Web servers)|   |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)|   |--- Load Balancer (Balance traffic among VM instances)|   |--- Storage Bucket (Store static content)この構成では、 環境毎にVM Instances 、Firewall Rules 、 Load Balancer 、Storage Bucket などのリソースが定義されていて環境間で異なるリソース設定を利用します。一方、moduleを使用した場合の構成は以下のようになります。Terraform Configuration|--- modules|   |--- user_service_cluster|       |--- main.tf|       |   |--- VM Instances (Web servers)|       |   |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)|       |   |--- Load Balancer (Balance traffic among VM instances)|       |   |--- Storage Bucket (Store static content)|       |--- variables.tf|       |--- output.tf|--- Development Environment|   |--- User-Service-Cluster  Module (source: ../modules/user_service_cluster)|--- Staging Environment|   |--- User-Service-Cluster Module (source: ../modules/user_service_cluster)|--- Production Environment|   |--- User-Service-Cluster  Module (source: ../modules/user_service_cluster)この構成では、 user_service_cluster moduleのmain.tfファイル内にVM Instances 、Firewall Rules 、 Load Balancer 、Storage Bucket などのリソースが定義されています。各環境はこのuser_service_clustermoduleを参照しており、環境間で共通のリソース設定を再利用します。これによって再利用性、可読性が上がり維持管理性を高める事ができると思います。moduleの使い方Terraformの moduleは、リソース設定の再利用可能な部品で、コードの抽象化と組織化をサポートします。 moduleは一つ以上のリソースを定義し、それらをまとめて管理することができます。 moduleを使用するためには、 moduleブロックをmain.tf（またはその他の.tfファイル）に追加し、そこでmoduleのソースと任意の入力変数を指定します。以下に、user_service_cluster moduleを使用するための基本的なmodule ブロックの例を示します。module "user_service_cluster" {  source = "../modules/user_service_cluster"  instance_type  = "n1-standard-1"  instance_count = 3  firewall_rules = {    allow_http  = true    allow_https = true  }  load_balancer_config = {    protocol = "HTTP"    port     = 80  }  bucket_name = "dev-bucket"}source属性にmoduleのソースコードが存在するパスを指定しています。そして、user_service_cluster moduleが定義する各入力変数を設定しています。moduleは、そのソース内でvariableブロックを使用して入力変数を定義します。これらの入力変数は、moduleの使用者が値を提供することでmoduleの振る舞いをカスタマイズできます。また、moduleはoutputブロックを使用して出力値を定義します。出力値は、moduleの内部リソースの属性をmoduleの外部に公開するために使用されます。これにより、他のリソースやmoduleがmoduleから生成されるリソースを参照することが可能になります。module化はTerraformのコードベースを組織化し、再利用可能なコードを作成するための重要な手段です。これにより、一貫性が保たれ、メンテナンスが容易になり、エラーの可能性も低減します。moduleの入力Terraformのmoduleは再利用可能なコードブロックで、入力変数（input variables）を使用してカスタマイズできます。これらの入力変数は、moduleブロックで設定します。以下に、user_service_cluster moduleで使用する入力変数の例を示します。まず、module自体のvariables.tfファイルには以下のように入力変数を定義しますvariable "instance_type" {  description = "The type of instance to start"  type        = string  default     = "n1-standard-1"}variable "instance_count" {  description = "Number of instances to create"  type        = number  default     = 1}variable "firewall_rules" {  description = "Firewall rules for instances"  type        = map(any)  default     = {}}variable "load_balancer_config" {  description = "Configuration for load balancer"  type        = map(any)  default     = {}}variable "bucket_name" {  description = "Name of the storage bucket"  type        = string  default     = "default-bucket"}そして、このmodule を呼び出す際に、具体的な値を設定します：module "user_service_cluster" {  source = "../modules/user_service_cluster"  instance_type  = "n1-standard-1"  instance_count = 3  firewall_rules = {    allow_http  = true    allow_https = true  }  load_balancer_config = {    protocol = "HTTP"    port     = 80  }  bucket_name = "dev-bucket"}上記の例では、user_service_cluster moduleはsourceで指定されたソースからロードされ、instance_type、instance_count、firewall_rules、load_balancer_config、bucket_nameという入力変数を設定しています。module に入力変数を提供することで、module の動作をカスタマイズし、異なる環境や条件で再利用することが可能になります。ローカルをうまく利用するTerraformのlocalsブロックを使用すると、再利用可能な内部変数をmodule内で定義することができます。localsはmodule内で共有され、module外からは参照できません。以下に、user_service_cluster module のlocalsの例を示します。この例では、HTTPポート、任意のポート、任意のプロトコル、TCPプロトコル、そして全てのIPアドレスをローカル変数として定義しています。locals {  http_port    = 80  any_port     = 0  any_protocol = "-1"  tcp_protocol = "tcp"  all_ips      = ["0.0.0.0/0"]}ローカル変数はlocal.<NAME>の形式で参照します。以下のリソース定義では、ロードバランサーリスナーとセキュリティグループの設定にローカル変数を使用しています。resource "google_compute_instance" "http" {  name         = "web-instance"  machine_type = "n1-standard-1"  network_interface {    network = "default"    access_config {      // Assign an ephemeral IP to the instance    }  }    // Other configuration...}resource "google_compute_firewall" "default" {  name    = "default-firewall"  network = "default"  allow {    protocol = local.tcp_protocol    ports    = [local.http_port]  }  source_ranges = local.all_ips}上記の例では、ロードバランサーリスナーとセキュリティグループでlocalsブロックに定義したローカル変数を参照しています。local.http_port、local.tcp_protocol、local.all_ipsを各リソースブロックで参照することで、コードがDRYに保たれ、より読みやすく、メンテナンスがしやすくなります。localsブロックを使用することで、コードの冗長性を減らし、module全体の一貫性を保つことができます。また、ローカル変数を使用することで、moduleの一部で使用する変数をmodule全体で共有することが可能になります。moduleの出力Terraformのmoduleは、出力変数（outputs）を提供できます。出力変数はmoduleの値を外部に公開するための手段で、moduleを使用しているコードからアクセスできます。また、Terraformがapplyコマンドを実行した後にこれらの値を表示することもできます。以下に、user_service_cluster moduleの出力変数の例を示します。この例では、output.tf にクラスタのURLとインスタンスのIDを出力しています。output "cluster_url" {  description = "The URL of the load balancer for the cluster"  value       = "http://${google_compute_global_address.default.address}"}output "instance_ids" {  description = "The IDs of the instances in the cluster"  value       = google_compute_instance.default.*.id}これらの出力をmodule の使用側でアクセスするためには、moduleの名前と出力の名前を組み合わせて参照します。output "user_service_cluster_url" {  description = "The URL of the load balancer for the user service cluster"  value       = module.user_service_cluster.cluster_url}output "user_service_cluster_instance_ids" {  description = "The IDs of the instances in the user service cluster"  value       = module.user_service_cluster.instance_ids}このようにして、moduleの出力変数を使用することで、moduleの内部データをmodule外部に公開し、他のTerraformコードがそのデータを参照できるようにします。出力変数はmodule間の情報共有を可能にし、moduleの再利用性を向上させます。Terraformはファイル名に特別な意味を持たせません。すなわち、variables.tfやoutputs.tfという名前は慣習にすぎないので、入力変数と出力変数を1つのファイルにまとめることも技術的には可能です。module を使ったときの失敗についてmodule を作る時に注意する点について実際にハマったことをベースに3つ紹介します。バージョンModuleのバージョンが異なると意図しない挙動やエラーが引き起こされる可能性があるので、バージョンを固定し実行環境を統一しましょう。Providerやパッケージにしても同じでバージョンを指定して再利用性を高めろ！！！状態の差分は可能な限り小さくすべきいつでもアップグレードを状態差分なしで行うことはできません。依存するリソースの変更やセキュリティ問題ができるだけ早くパッチを適用する必要があるなど、破壊的な変更を導入する必要がある場合があります。その場合、コストをどのように減らすかについて考える必要があります。状態の差分が少なければ、アップグレードのコストは少なくなります。破壊的な変更を導入するときは、それを文書化できるCHANGELOGやユーザーガイドを通じてユーザーに伝える必要がありますアップグレードは自動されるべきアップグレードは長期的に開発されるソフトウェアの最も重要なタスクの一つです。ただし、一般的に使用され、広く使用されているTerraform Moduleの場合、これは大きな問題でもあります。また、Moduleを頻繁に更新する場合、自動アップデートの機能を準備する必要があります。ユーザーにアップグレードを依頼しても、通常、彼らはより重要なタスクを行うためにそれを行うことはありません。そのため、代わりに、彼らのためにPRを作成します。PRがTerraformの差分がない場合に自動的にマージされるメカニズムを持っています。これと後方互換性の維持の組み合わせにより、最新バージョンのModuleを使用するユーザーの率を増やすことができますファイルパスTerraformのtemplatefile関数を使用する際、ファイルパスは絶対パスではなく相対パスを使用する必要があります。しかし、これはどのパスに対して相対的なのでしょうか？デフォルトでは、Terraformはパスを現在の作業ディレクトリに対して相対的に解釈します。そのため、terraform applyを実行しているディレクトリと同じディレクトリにTerraform設定ファイルがある場合、これはうまく動作します。しかし、別のフォルダに定義されたmodule内でtemplatefileを使用する場合、これは問題となります。この問題を解決するためには、path.moduleなどのパス参照を使用します。これを使用すると、module自体に対する相対パスが得られます。インラインブロックTerraformリソースの一部の設定は、インラインブロックか別のリソースとして定義することができます。インラインブロックとは、リソース内で設定する引数のことで、次の形式を持っています。resource "xxx" "yyy" {  <NAME> {    [CONFIG...]  }}ここでNAMEはインラインブロックの名前（例えば、ingress）、CONFIGはそのインラインブロックに特有の一つ以上の引数（例えば、from_portやto_port）です。しかし、インラインブロックと別のリソースを混在して使用すると、Terraformの設計上、設定が衝突し互いに上書きされてエラーが発生します。したがって、どちらか一方を使用する必要があります。moduleを作成する際には、別のリソースを使用することを常に推奨します。これらの注意点を理解しておくことで、Terraformのmoduleをより効果的に利用することができます。いい感じのデフォルトの変数完全にカスタマイズできるModuleには魅力がないです。Moduleの変数には、80％のユーザーをカバーするスマートデフォルト値を持つべきです。ただし、同時に、通常のユーザーとは異なる方法でModuleを使用するパワーユーザーのための設定も用意するべきです。変数を変更したときに何が起こるかは、ユーザーにとって明白で予測可能でなければなりません。この設定は適切に設計され、安易に浅いインターフェースを持つべきではありません最後にmoduleを活用することで、インフラストラクチャの再利用性と効率性が大幅に向上します。開発者は証明済み、テスト済み、文書化済みのインフラストラクチャの一部を再利用できるようになるため、迅速かつ確実にシステムを構築できます。例えば、マイクロサービスのデプロイメントを定義するmoduleを作成し、各チームが数行のコードで自身のマイクロサービスを管理できるようにすることが可能です。しかし、このようなmoduleを複数のチームで活用するためには、module内のTerraformコードは柔軟性と設定可能性が必要です。異なるチームや状況に応じて、ロードバランサーなしの単一インスタンスやロードバランサー付きの複数インスタンスといった、さまざまなデプロイメント要件を満たすことができます。Terraformの柔軟な構文を活用することで、より多機能なmoduleを設計し、インフラストラクチャの構築を一層楽しく効果的に行うことができます。また、どれぐらいの規模からmodule化するのかなど迷う場面が多いと思いますがこの辺は経験としか言えずにみんな雰囲気でやっているなぁって思いました。このブログが伸びたらもっと実装に基づいた話をしていこうと思います。ちなみにベストプラクティスなんかは俺にはわからない。自分を信じても…信頼に足る仲間を信じても…誰にもわからない…今の構成が一番変更しやすくて誇れるものならそれが正解なんだとおもう。実践Terraform　AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)作者:野村 友規インプレスR&DAmazon参考Terraform: Up & Running; Writing Infrastructure As CodeDeveloper/Terraform/Configuration Language/Modulesterraform-module/terraform-module-blueprinthttps://registry.terraform.io/namespaces/terraform-aws-moduleshttps://registry.terraform.io/namespaces/terraform-google-modulesHashiCorp LearnModule Creation - Recommended PatternAWSとTerraformで学ぶプロダクションレディなKubernetes 技術の泉シリーズ (技術の泉シリーズ（NextPublishing）)

Terraform Modules で再利用できるので最高ではないでしょうか？

はてなブログの設定から、Markdown記法で書いた記事にコードブロックのコピーボタンを自動的に追加することができます。また、こちらのブログは完全に非公式ですし自分のブログ以外では試してません。🦾 デザインの設定まず、はてなブログの管理画面にログインし、デザイン設定を開きます。🦾 CSS の設定を行うデザイン設定で、「カスタマイズ」タブをクリックし、「デザインCSS」を開きます。ここで、先ほど紹介したコピーボタンのスタイルを追加します。pre.code {  position: relative;}.copy-button {  position: absolute;  top: 4px;  right: 4px;  display: inline-block;  padding: 8px 16px;  border: none;  border-radius: 4px;  background-color: #1e90ff;  color: #ffffff;  cursor: pointer;  font-size: 14px;  font-weight: bold;  text-decoration: none;  box-shadow: 0 2px 4px rgba(0, 0, 0, 0.2);  transition: background-color 0.3s, box-shadow 0.3s;  opacity: 0;  transition: opacity 0.3s;}pre.code:hover .copy-button {  opacity: 1;}.copy-button:hover {  background-color: #2980b9;  box-shadow: 0 4px 8px rgba(0, 0, 0, 0.4);}.copy-button:focus {  outline: none;}.copy-button:active {  box-shadow: none;  transform: translateY(2px);}🦾 フッターHTMLの設定を行う 次に、「カスタマイズ」タブの「フッターHTML」に、以下のコードを追加します。<script>  document.addEventListener('DOMContentLoaded', function() {    // コードブロックを取得    var codeBlocks = document.querySelectorAll('pre.code');        // すべてのコードブロックにコピーボタンを追加    for (var i = 0; i < codeBlocks.length; i++) {      var copyButton = document.createElement('button');      copyButton.className = 'copy-button';      copyButton.textContent = 'Copy code';      copyButton.onclick = function() {        var codeElem = this.parentNode.querySelector('code') || this.parentNode;        var textArea = document.createElement('textarea');        textArea.value = codeElem.textContent.replace(/Copy code$/, ''); // "Copy code" テキストを削除        document.body.appendChild(textArea);        textArea.select();        document.execCommand('copy');        document.body.removeChild(textArea);      }      codeBlocks[i].appendChild(copyButton);    }  });</script>🔍 確認していくhttps://syu-m-5151.hatenablog.com/entry/2023/04/11/084428 にて確認

はてなブログのコードブロックを”クリップボードにコピーする方法”について

はじめにもし、アプリケーションに実装できるならそれが良いです。独自に実装などせずにエンドポイントにて500 Internal Server Errorが多発していればアラートをすれば良いので...。こちらの続編になります。syu-m-5151.hatenablog.com本エントリーでは、GolangでEchoフレームワークを使用し、Prometheus ExporterをMiddlewareとして実装する方法について説明します。Prometheus Middlewareは、自動でMetrics を生成します。これにより、アプリケーションのパフォーマンス監視や問題解析が容易になります。利用しているコードはこちらgithub.comはじめにコードを解説するんじゃいvarinitmeasureExternalAccessunstableEndpointMiddlewareを適用Prometheus Middlewareを適用EchoのMiddlewareについてEcho Echo Middleware の特徴再び、Docker Compose での実行するんじゃろがい見れたぞぉおおおおさいごにコードを解説するんじゃいシンプルだけど解説をします。環境構築などは前回のエントリーに任せます。Echoフレームワークを使ってGolangでシンプルなWebアプリケーションを作成し、Prometheus Exporterをミドルウェアとして実装する例です。package mainimport (    "math/rand"    "net/http"    "time"    "github.com/labstack/echo-contrib/prometheus"    "github.com/labstack/echo/v4"    "github.com/labstack/echo/v4/middleware"    prom "github.com/prometheus/client_golang/prometheus")// Prometheus のメトリクスを定義しています。// これらのメトリクスは、3-shake.com への外部アクセスの情報を収集するために使用されます。var (    externalAccessDuration = prom.NewHistogram(        prom.HistogramOpts{            Name:    "external_access_duration_seconds",            Help:    "Duration of external access to 3-shake.com",            Buckets: prom.DefBuckets,        },    )    lastExternalAccessStatusCode = prom.NewGauge(        prom.GaugeOpts{            Name: "last_external_access_status_code",            Help: "Last status code of external access to 3-shake.com",        },    ))// init 関数内で、メトリクスを Prometheus に登録しています。func init() {    prom.MustRegister(externalAccessDuration)    prom.MustRegister(lastExternalAccessStatusCode)}// 3-shake.com の外部アクセスを計測するミドルウェアを作成します。func measureExternalAccess(next echo.HandlerFunc) echo.HandlerFunc {    return func(c echo.Context) error {        // HTTP クライアントを作成し、タイムアウトを 10 秒に設定します。        client := &http.Client{Timeout: 10 * time.Second}        // 現在の時刻を取得し、アクセス開始時間として保持します。        startTime := time.Now()        // 3-shake.com に対して HTTP GET リクエストを送信します。        resp, err := client.Get("https://3-shake.com")        // アクセス開始時間から現在の時刻までの経過時間を計算し、duration に格納します。        duration := time.Since(startTime)        // エラーが発生しない場合（リクエストが成功した場合）        if err == nil {            // アクセス時間（duration）をヒストグラムメトリクスに追加します。            externalAccessDuration.Observe(duration.Seconds())            // ステータスコードをゲージメトリクスに設定します。            lastExternalAccessStatusCode.Set(float64(resp.StatusCode))            // レスポンスのボディを閉じます。            resp.Body.Close()        }        // 次のミドルウェアまたはハンドラ関数に処理を移します。        return next(c)    }}func unstableEndpoint(c echo.Context) error {    // 0 から 4 までのランダムな整数を生成します。    randomNumber := rand.Intn(5)    // 生成された整数が 4 の場合、HTTP ステータスコード 500 を返します。    if randomNumber == 4 {        return c.String(http.StatusInternalServerError, "Something went wrong!")    }    // それ以外の場合、HTTP ステータスコード 200 を返します。    return c.String(http.StatusOK, "Success!")}func main() {    e := echo.New()    // ミドルウェアの設定    e.Use(middleware.Logger())    e.Use(middleware.Recover())    // Prometheus ミドルウェアを有効にします。    p := prometheus.NewPrometheus("echo", nil)    p.Use(e)    // 3-shake.com への外部アクセスを計測するミドルウェアを追加します。    e.Use(measureExternalAccess)    // ルートのエンドポイントを設定します。    e.GET("/", func(c echo.Context) error {        return c.String(http.StatusOK, "Hello, World!")    })    // /unstable エンドポイントを設定します。    // 20% の確率で HTTP ステータスコード 500 を返します。    e.GET("/unstable", unstableEndpoint)    // サーバーを開始します。    e.Start(":2121")}varvarで3-shake.com への外部アクセスの情報を収集するための Prometheus メトリクスを定義していきます。var (    externalAccessDuration = prom.NewHistogram(        prom.HistogramOpts{            Name:    "external_access_duration_seconds",            Help:    "Duration of external access to 3-shake.com",            Buckets: prom.DefBuckets,        },    )    lastExternalAccessStatusCode = prom.NewGauge(        prom.GaugeOpts{            Name: "last_external_access_status_code",            Help: "Last status code of external access to 3-shake.com",        },    ))echo.labstack.cominitinit 関数でメトリクスを Prometheus に登録します。func init() {    prom.MustRegister(externalAccessDuration)    prom.MustRegister(lastExternalAccessStatusCode)}measureExternalAccessmeasureExternalAccess関数で3-shake.com への外部アクセスを計測するミドルウェアを定義します。こちらの方がEcho Likeな定義の仕方だと思うので好きです。Echo のカスタムミドルウェアで、リクエストが処理される前に 3-shake.com への外部アクセスを計測する役割を持っています。func measureExternalAccess(next echo.HandlerFunc) echo.HandlerFunc {    return func(c echo.Context) error {        // HTTP クライアントを作成し、タイムアウトを 10 秒に設定します。        client := &http.Client{Timeout: 10 * time.Second}        // 現在の時刻を取得し、アクセス開始時間として保持します。        startTime := time.Now()        // 3-shake.com に対して HTTP GET リクエストを送信します。        resp, err := client.Get("https://3-shake.com")        // アクセス開始時間から現在の時刻までの経過時間を計算し、duration に格納します。        duration := time.Since(startTime)        // エラーが発生しない場合（リクエストが成功した場合）        if err == nil {            // アクセス時間（duration）をヒストグラムメトリクスに追加します。            externalAccessDuration.Observe(duration.Seconds())            // ステータスコードをゲージメトリクスに設定します。            lastExternalAccessStatusCode.Set(float64(resp.StatusCode))            // レスポンスのボディを閉じます。            resp.Body.Close()        }        // 次のミドルウェアまたはハンドラ関数に処理を移します。        return next(c)    }}unstableEndpointちゃんと、メトリクス値が取得できているか確認したいのでunstableEndpointというエンドポイントを追加し、リクエストのうち約 5 回に 1 回失敗するように実装しました。このエンドポイントは、リクエストが成功した場合には HTTP ステータスコード 200 を返し、失敗した場合には HTTP ステータスコード 500 を返します。func unstableEndpoint(c echo.Context) error {    // 0 から 4 までのランダムな整数を生成します。    randomNumber := rand.Intn(5)    // 生成された整数が 4 の場合、HTTP ステータスコード 500 を返します。    if randomNumber == 4 {        return c.String(http.StatusInternalServerError, "Something went wrong!")    }    // それ以外の場合、HTTP ステータスコード 200 を返します。    return c.String(http.StatusOK, "Success!")}curl してくるワンライナー(fish)も用意しましたので思う存分curl してください。for i in (seq 1 50); curl http://localhost:2121/unstable; echo ""; endMiddlewareを適用寂しいのでPrometheus 以外のMiddlewareをEchoインスタンスに適用しました。middleware.Logger() : リクエストのログを出力するMiddlewaremiddleware.Recover() : パニックを回復してアプリケーションがクラッシュしないようにするMiddleware   e.Use(middleware.Logger())    e.Use(middleware.Recover())Prometheus Middlewareを適用これだけなんです。Echo用の新しいPrometheus Middlewareインスタンスを作成します。作成したPrometheus MiddlewareインスタンスをEchoインスタンスに適用します。 // Prometheusミドルウェアを適用する    p := prometheus.NewPrometheus("echo", nil)    p.Use(e)EchoのMiddlewareについてMiddlewareは、リクエストとレスポンスの処理の前後にカスタムロジックを実行するための仕組みを提供しています。EchoのMiddlewareは、コードの再利用性、可読性、そして機能の分離を向上させるために役立ちます。>Logger: Request    Logger->>Middleware1: Processed Request    Middleware1->>Recovery: Processed Request    Recovery->>Prometheus: Processed Request    Prometheus->>CORS: Processed Request    CORS->>Handler: Processed Request    Handler->>CORS: Response    CORS->>Prometheus: Processed Response    Prometheus->>Recovery: Processed Response    Recovery->>Middleware1: Processed Response    Middleware1->>Logger: Processed Response    Logger->>Client: Processed Responsemermaid.initialize({startOnLoad: true});echo.labstack.comEcho Echo Middleware の特徴Middlewareは、複数のMiddleware関数を組み合わせて実行することができます。これにより、機能を組み合わせてカスタム処理パイプラインを構築することができます。これらは登録された順序で実行されます。これにより、処理の流れを明確にし、簡単に制御できるようになります。また、Echoでは、これらをグローバルに適用することも、特定のルートに適用することもできます。これにより、アプリケーション全体または特定のエンドポイントに対してカスタム処理を適用できます。Echoは、いくつかの組み込みミドルウェアを提供していますが独自のカスタムミドルウェアを作成してアプリケーションに適用することもできます。e := echo.New()e.Use(middleware.Logger()) # 登録された順序で実行されるぞe.GET("/",getHallo,middleware.Recover()) # e.GET("/", <Handler>, <Middleware...>) で特定のルートにだけMiddlewareを登録できるe.Use(LoggingMiddleware) # 独自で実装するカスタムミドルウェアecho.labstack.com再び、Docker Compose での実行するんじゃろがい完全に同じことやってるのでこちらを参考にしてくださいsyu-m-5151.hatenablog.com見れたぞぉおおおおhttp://localhost:2121/metrics の結果もこちらに記載しておきますgithub.comGolang のEcho でMiddlewareを使ってアプリケーションのPrometheus Exporter を実装することができました。アラートの設定方法については他のブログを参照してください。さいごに以上で、Echo フレームワークを使って、Prometheus メトリクスを追加し、さらに不安定なエンドポイントを作成する方法を解説しました。この知識を活かして、みなさんのアプリケーションにメトリクスを取得する機能を追加して、可観測性を向上させましょう！全然、関係ないけど翻訳に携わってコンテナセキュリティのブラックボックス感が多少薄まるのでみんな読んでくれ...コンテナセキュリティ　コンテナ化されたアプリケーションを保護する要素技術作者:Liz RiceインプレスAmazon

Golang のEcho でMiddlewareを使ってPrometheus Exporter を実装する

はじめにPrometheus でアプリケーションの構築をしているとどうしてもこの値が取りたいのに... と思うことが多々ある。Pushgateway も選択肢として上げられるが今回は選択肢を増やしてほしいという意味でもExporterの実装方法について検討していきます。ExporterはPrometheusのpull モデルに適合し、監視対象のライフサイクルと一貫性があり、スケーラビリティと自動検出の利点を享受できるため、Pushgatewayよりも推奨される方法です。ただし、特定のユースケース（サービスレベルのバッチジョブなど）では、Pushgatewayの使用が適切な場合もあります。Pushgatewayを使う際には以下の問題点があるので注意が必要です。複数のインスタンスを1つのPushgatewayで監視すると、単一障害点とボトルネックが発生する可能性がある。Prometheusの自動インスタンスヘルスチェックが利用できなくなる。Pushgatewayは一度プッシュされたデータを忘れず、手動でAPIを通じて削除しない限り永久にPrometheusで公開されてしまう。Exporter の実装と運用はそこそこ手間になるので最適な方法を選んでほしいです。この辺はCloudを利用しても同じような問題があるので注意しながらやっていきましょう。はじめにExporterとはPrometheusの公式クライアントライブラリやっていくぞ！おら！環境構築実装についてコードを解説するんじゃいPrometheusのメトリクスを定義init関数registerMetrics関数updateMetrics関数prometheusMiddleware関数measureExternalAccess関数var 配下ってことぉおおおhttpRequestsTotalhttpRequestDurationhttpRequestSizehttpResponseSizehttpResponseTimeexternalAccessDurationDocker Compose での実行するんじゃろがいprometheus.ymldocker-compose.ymlDockerfiledocker compose の実行さいごにサンプルコードはこちらです。サンプルコード自体は雑多な作業リポジトリにおいてあるのでご注意ください。また、アプリケーション自体のリソースを確認するのにEcho のミドルウェアを使用していません。自身の利用しているライブラリーにPrometheus のエンドポイントを提供する機能がないか調べておきましょう。gRPCのGo Server にも同様の機能があります。あと、外部のリソースが確認したいだけならBlackbox exporterという選択肢もあります。github.comExporterとはExporterは、Prometheusがメトリクスを収集するために使用するプログラムです。Exporterは、アプリケーションやインフラストラクチャからメトリクスを収集し、Prometheusが理解できる形式に変換して提供します。公式ドキュメントで提供されているExporter一覧は、こちらを参照してください。Prometheusの公式クライアントライブラリPrometheusは、いくつかの言語用の公式クライアントライブラリを提供しており、これを使用してExporterを実装することができます。今回はGoで実装していくのこちらが参考になると思います。やっていくぞ！おら！やっていきます環境構築# Go のモジュールを作成する。必要なライブラリーはのちほど`go mod tidy` で持ってくる。go mod init prometheus-go-exporter実装について以下をmain.go に配置して実行(go run main.go)してください。以下のコードはEchoを利用したWebサーバーにPrometheusのExporterを実装し、3-shake.comへのアクセスを計測しています。http://localhost:2121/3-shake-status や http://localhost:2121/metrics で値を取得できていると思います。package mainimport (    "fmt"    "net/http"    "time"    "github.com/labstack/echo/v4"    "github.com/labstack/echo/v4/middleware"    "github.com/prometheus/client_golang/prometheus"    "github.com/prometheus/client_golang/prometheus/promhttp")// Prometheusのメトリクスを定義しています。// これらのメトリクスは、HTTPリクエストの情報や3-shake.comへのアクセス情報を収集するために使用されます。var (    httpRequestsTotal = prometheus.NewCounterVec(        prometheus.CounterOpts{            Name: "http_requests_total",            Help: "Number of HTTP requests processed",        },        []string{"method", "path"},    )    httpRequestDuration = prometheus.NewHistogramVec(        prometheus.HistogramOpts{            Name:    "http_request_duration_seconds",            Help:    "Duration of HTTP requests",            Buckets: prometheus.DefBuckets,        },        []string{"method", "path"},    )    httpRequestSize = prometheus.NewHistogramVec(        prometheus.HistogramOpts{            Name:    "http_request_size_bytes",            Help:    "Size of HTTP requests",            Buckets: prometheus.ExponentialBuckets(128, 2, 10),        },        []string{"method", "path"},    )    httpResponseSize = prometheus.NewHistogramVec(        prometheus.HistogramOpts{            Name:    "http_response_size_bytes",            Help:    "Size of HTTP responses",            Buckets: prometheus.ExponentialBuckets(128, 2, 10),        },        []string{"method", "path"},    )    httpResponseTime = prometheus.NewGaugeVec(        prometheus.GaugeOpts{            Name: "http_response_time_seconds",            Help: "Time of the last HTTP response",        },        []string{"method", "path"},    )    externalAccessDuration = prometheus.NewHistogram(        prometheus.HistogramOpts{            Name:    "external_access_duration_seconds",            Help:    "Duration of external access to 3-shake.com",            Buckets: prometheus.DefBuckets,        },    )    lastExternalAccessStatusCode = prometheus.NewGauge(        prometheus.GaugeOpts{            Name: "last_external_access_status_code",            Help: "Last status code of external access to 3-shake.com",        },    ))// init関数内で、メトリクスをPrometheusに登録しています。func init() {    registerMetrics()}// registerMetrics関数では、Prometheusにメトリクスを登録しています。// これにより、Prometheusがメトリクスを収集できるようになります。func registerMetrics() {    prometheus.MustRegister(httpRequestsTotal)    prometheus.MustRegister(httpRequestDuration)    prometheus.MustRegister(httpRequestSize)    prometheus.MustRegister(httpResponseSize)    prometheus.MustRegister(httpResponseTime)    prometheus.MustRegister(externalAccessDuration)    prometheus.MustRegister(lastExternalAccessStatusCode)}// updateMetrics関数では、受信したHTTPリクエストのメトリクスを更新しています。// これにより、各リクエストに関する情報が収集されます。func updateMetrics(method, path string, requestSize, responseSize int, duration time.Duration) {    httpRequestsTotal.WithLabelValues(method, path).Inc()    httpRequestDuration.WithLabelValues(method, path).Observe(duration.Seconds())    httpRequestSize.WithLabelValues(method, path).Observe(float64(requestSize))    httpResponseSize.WithLabelValues(method, path).Observe(float64(responseSize))    httpResponseTime.WithLabelValues(method, path).Set(float64(time.Now().Unix()))}// prometheusMiddleware関数では、Echoのミドルウェアとして、受信したHTTPリクエストに関するメトリクスを更新する機能を追加しています。func prometheusMiddleware(next echo.HandlerFunc) echo.HandlerFunc {    return func(c echo.Context) error {        startTime := time.Now()        err := next(c)        duration := time.Since(startTime)        requestSize := c.Request().ContentLength        responseSize := c.Response().Size        updateMetrics(c.Request().Method, c.Path(), int(requestSize), int(responseSize), duration)        return err    }}// measureExternalAccess関数では、3-shake.comへの外部アクセスを定期的に計測し、そのアクセス時間とステータスコードをメトリクスに格納しています。// この関数はメイン関数内で呼び出され、別のゴルーチンで実行されます。func measureExternalAccess() {    client := &http.Client{Timeout: 10 * time.Second}    go func() {        for {            startTime := time.Now()            resp, err := client.Get("https://3-shake.com")            duration := time.Since(startTime)            if err == nil {                externalAccessDuration.Observe(duration.Seconds())                lastExternalAccessStatusCode.Set(float64(resp.StatusCode))                resp.Body.Close()            }            time.Sleep(1 * time.Minute)        }    }()}func main() {    // Echo instance    e := echo.New()    // Middleware for Prometheus Exporter    e.Use(prometheusMiddleware)    // Enable request logger    e.Use(middleware.Logger())    e.GET("/3-shake-status", func(c echo.Context) error {        status := lastExternalAccessStatusCode.Desc().String()        return c.String(http.StatusOK, fmt.Sprintf("Last 3-shake.com access status: %s", status))    })    // Prometheus Exporter endpoint    e.GET("/metrics", echo.WrapHandler(promhttp.Handler()))    // Measure external access to 3-shake.com    measureExternalAccess()    // Start the server    e.Start(":2121")}コードを解説するんじゃい解説をします。Prometheusのメトリクスを定義Prometheusのメトリクスを定義しています。これらのメトリクスは、HTTPリクエストの情報や3-shake.comへのアクセス情報を収集するために使用されます。var (    // ... (省略)    externalAccessDuration = prometheus.NewHistogram(        prometheus.HistogramOpts{            Name:    "external_access_duration_seconds",            Help:    "Duration of external access to 3-shake.com",            Buckets: prometheus.DefBuckets,        },    )    lastExternalAccessStatusCode = prometheus.NewGauge(        prometheus.GaugeOpts{            Name: "last_external_access_status_code",            Help: "Last status code of external access to 3-shake.com",        },    ))init関数init関数内で、メトリクスをPrometheusに登録しています。func init() {    registerMetrics()}registerMetrics関数registerMetrics関数では、Prometheusにメトリクスを登録しています。これにより、Prometheusがメトリクスを収集できるようになります。func registerMetrics() {    // ... (省略)    prometheus.MustRegister(externalAccessDuration)    prometheus.MustRegister(lastExternalAccessStatusCode)}updateMetrics関数updateMetrics関数では、受信したHTTPリクエストのメトリクスを更新しています。これにより、各リクエストに関する情報が収集されます。func updateMetrics(method, path string, requestSize, responseSize int, duration time.Duration) {    // ... (省略)}prometheusMiddleware関数prometheusMiddleware関数では、Echoのミドルウェアとして、受信したHTTPリクエストに関するメトリクスを更新する機能を追加しています。func prometheusMiddleware(next echo.HandlerFunc) echo.HandlerFunc {    // ... (省略: )}measureExternalAccess関数measureExternalAccess関数 では、3-shake.comへの外部アクセスを定期的に計測し、そのアクセス時間とステータスコードをメトリクスに格納しています。この関数はメイン関数内で呼び出され、別のゴルーチンで実行されます。func measureExternalAccess() {    client := &http.Client{Timeout: 10 * time.Second}    go func() {        for {            startTime := time.Now()            resp, err := client.Get("https://3-shake.com")            duration := time.Since(startTime)            if err == nil {                externalAccessDuration.Observe(duration.Seconds())                lastExternalAccessStatusCode.Set(float64(resp.StatusCode))                resp.Body.Close()            }            time.Sleep(1 * time.Minute)        }    }()}var 配下ってことぉおおおPrometheusのメトリクスを定義しています。この辺の実装はよく悩むと思うので公式の実装とかたくさん読むと何をどれに使えばよいかの勘所が掴めると思います。実際に使わないと差が分からないのでとっとと手を動かすのがオススメです。httpRequestsTotal処理されたHTTPリクエストの総数をカウントするメトリクスです。prometheus.NewCounterVec関数を使用して定義され、リクエストのメソッド（GET、POSTなど）とパス（リソースへのURLパス）によってラベル付けされます。httpRequestDurationHTTPリクエストの処理時間を記録するメトリクスです。prometheus.NewHistogramVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。デフォルトのバケットは、prometheus.DefBucketsを使用して設定されます。httpRequestSizeHTTPリクエストのサイズ（バイト単位）を記録するメトリクスです。prometheus.NewHistogramVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。バケットは、prometheus.ExponentialBuckets関数を使用して設定されます。httpResponseSizeHTTPレスポンスのサイズ（バイト単位）を記録するメトリクスです。prometheus.NewHistogramVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。バケットは、同様にprometheus.ExponentialBuckets関数を使用して設定されます。httpResponseTimeHTTPレスポンスの時間を記録するメトリクスです。このメトリクスは、prometheus.NewGaugeVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。externalAccessDurationこれは、3-shake.comへの外部アクセスの持続時間を記録するメトリクスです。このメトリクスは、prometheus.NewHistogram関数を使用して定義されます。デフォルトのバケットは、prometheus.DefBuckets関数を使用して設定されます。Docker Compose での実行するんじゃろがいprometheus.ymlまず、prometheus.ymlを作成します。このファイルには、Prometheusがどのようにメトリクスを収集するかについての設定が含まれています。global:  scrape_interval: 15sscrape_configs:  - job_name: 'echo_exporter'    static_configs:      - targets: ['echo_exporter:2121']docker-compose.yml次に、docker-compose.ymlを作成します。このファイルには、PrometheusとGolangのEchoアプリケーションを実行するために必要なコンテナの設定が含まれています。version: '3.8'services:  echo_exporter:    build:       context: .      dockerfile: Dockerfile_exporter    ports:      - "2121:2121"  prometheus:    image: prom/prometheus:latest    volumes:      - ./prometheus.yml:/etc/prometheus/prometheus.yml    command:      - "--config.file=/etc/prometheus/prometheus.yml"    ports:      - "9090:9090"DockerfileDockerfileを作成して、Echoアプリケーションをコンテナで実行できるようにします。別に動けばよいのでなんか工夫とかはしてないです。本番でやるときはうまくマルチステージビルドとか使って下さい。# Use the official Golang image as the base imageFROM golang:1.20# Set the working directoryWORKDIR /app# Copy go.mod and go.sum to download dependenciesCOPY go.mod go.sum ./# Download dependenciesRUN go mod download# Copy the source codeCOPY . .# Build the applicationRUN go build -o main .# Expose the port the application will run onEXPOSE 2121# Run the applicationCMD ["./main"]docker compose の実行2023 年 6 月末から、Compose V1 はサポートされなくなり、すべての Docker Desktop バージョンから削除されるので注意してほしいです。ちなみにcompose がdockerコマンドに入るようになったのでdocker-compose 特別にインストールせずとも実行可能になりました。# デーモン化しちゃうdocker compose up -d Dockerfileを使用してecho_exporterサービスがビルドされ、PrometheusとGolangのEchoアプリケーションをそれぞれのコンテナで起動します。Prometheusは、echo_exporterサービスからメトリクスを収集し、ポート9090でアクセスできるようになります。last_external_access_status_code を確認するには起動した状態でこちらを参考にしてください。一回、シャットダウンしたので以下のようなグラフが出力されていますね。。長くなったのでこれで終わります。さいごに実は Echo において Prometheus は、HTTP リクエストのメトリックを生成することができるミドルウェアを提供しているので基本的な部分でコードを書く必要がありません。もし、アプリケーションに実装できるならそれが良いです。独自に実装などせずにエンドポイントにて500 Internal Server Errorが多発していればアラートをすれば良いだけなので...。もし、インフラのコードがアプリに組み込めないもしくはプロダクションコードは開発側しか触れない時には協力を仰いで下さい。開発側との人間関係に問題があったりセキュリティ上の課題がある場合には別の手段を考えましょう。package mainimport (    "github.com/labstack/echo/v4"    "github.com/labstack/echo-contrib/prometheus")func main() {    e := echo.New()    // Enable metrics middleware    p := prometheus.NewPrometheus("echo", nil)    p.Use(e)    e.Logger.Fatal(e.Start(":1323"))}と書くだけで外部リソースへのアクセス以外のメトリクスは提供できます。また、外部リソースに対してもいくつかの構造体を持っているのでこれらも効率的に提供できます。echo.labstack.com本当に関係ないんですけど2023年4月19日にECサイト構築・運用セキュリティガイドラインを読み解く会 というのをやるので興味あれば！owasp-kyushu.connpass.com続編のブログも書いておきました。syu-m-5151.hatenablog.comPrometheus実践ガイド: クラウドネイティブな監視システムの構築作者:仲亀 拓馬テッキーメディアAmazon

Golang のEcho で Prometheus Exporter を実装する

はじめにソフトウェアの問題解決に関する提案してくれるプロンプトを利用することは、今後の開発者やエンジニアがより効率的に問題解決を行うための重要な手段の一つになります。というか毎回、適切なプロンプトを作成するのが面倒になった。このプロンプトには、ソフトウェア開発におけるベストプラクティスやDevOps、SRE方法論などの知識や経験が共有され、開発者やエンジニアの能力向上に貢献することができるようになれば良いなーと妄想しております。GPT4 のみを対象にしています。GPT3.5 で改善を試みたけど4ほど良い内容が返ってこない。効果ユーザーの問題を効果的に解決するための具体的なソリューションを提案します。DevOpsとSREの手法を活用して、ユーザーのソフトウェア開発プロセスを改善します。ユーザーとのコミュニケーションを通じて、問題解決の過程でのフィードバックを得ることができます。想定するユーザーソフトウェア開発者やDevOpsエンジニアで、ベストプラクティスや新しい技術の導入に興味がある方。経験豊富なコンサルタントや専門家のアドバイスを求めている企業やチームのメンバー。注意点提案するソリューションは、ユーザーの業界や技術スタックに適合するように調整する必要があります(こちらあまり価値がないことに気付いたので削除いたしました)。プロンプトの手順に従って、ユーザーからのフィードバックを適切に反映するように注意してください。顧客の承認が得られるまで、適切な提案を続けてください。プロンプト(2023/05/01)# Goal:- You suggest software best practices, DevOps, and SRE methodologies properly and appropriately according to the following rules and steps.# Context:- You are an experienced DevOps engineer and software developer.- You are a supportive and attentive consultant.- Please use Japanese.# Rules- You must keep acting like the consultant, DevOps engineer, and software developer defined in the Context above throughout the Steps below.- You always remember that you're in the Context described above.# Steps: execute the following steps one by one.- Ask the customer what problem they want to solve.- Confirm that the target issue has been correctly identified.- If the confirmation is approved, proceed to the next step. If not, return to the second step.- Based on the customer's situation, make several suggestions for resolving the issue, including specific best practices, tools, or methodologies.- Please provide an appropriate software implementation, if any, for your proposed solution.- Please provide any references for your proposed solution.- Ask for feedback on the suggestions you made. If a positive message is given, further explain the suggestion if you made it. If not, make another suggestion.- Ask if the customer wants to repeat the steps in solving the same issue or if they want you to make a new proposal. If they want to repeat, go back to the second step. If not, give a positive message so that they get the issue they want to solve.書籍でオススメでいうと「言葉の意味とは何か」がテーマである本書。LLMとの付き合い方を考えることができるのでオススメです。あと、当たり前にこのブログの文章はChatGPTが生成したものを加筆、修正してます。働きたくないイタチと言葉がわかるロボット 人工知能から考える「人と言葉」作者:川添愛朝日出版社Amazon

ChatGPT:SREやDevOpsなどのソフトウェアの運用に伴う課題解決に関する提案を行うプロンプト

fortee.jpPHPカンファレンスという舞台に、いかなる因果でDevOpsとSREの話を提案することとなりました。これは、PHPを主題とするカンファレンスでありながら、「PHPじゃないけどどうしても伝えたい話がある！」という寛大な運営方針に導かれたためでございます。そんな折、もし採択される運命に導かれたならば、我々の組織においてDevOpsとSREが如何に役立ち、開発と運用の世界で如何に応用できるか、その真髄をカンファレンスで共有することを目指しております。基本概念を理解し、現状を評価し、適切なプラクティスを選び、効果を測定し、継続的に改善することで、開発と運用の連携が強化され、効率的で信頼性の高いシステムが構築されることをお伝えする所存でございます。多くの優れた提案が集まる中で、我が提案が採択される確率は微かですが、もし運命の導きによって叶うことがあれば、福岡へと凱旋いたします。その時、遥かな地平線の果てに、願いが届くことを切に願っています。どうか、お力をお貸しください。参考PHPカンファレンス福岡2023に｢カンファレンスのつくりかた｣というproposalを出しました - Masteries

PHPカンファレンス福岡2023に｢State of DevOps 2022を読みながら、組織に適したSREの実践方法を探求する｣というproposalを出しました #phpconfuk 

Vimerを自称したい人間がいる。お前である。 Vimであることに執着して開発メンバーで唯一人Vimを使っている人間がいる。これもお前である。Vimに対する愛と執念を振りまく人間がいる。まさしくお前である。画像https://www.lunarvim.org/ より引用はじめに1年前にVimからNeovimへの旅立ちを行った私は、新たなエディタの世界に足を踏み入れることに興奮を覚えました。Vimという古き良き時代のエディタから、Neovimという最先端の技術を取り入れた新世代のエディタへと変わる過程は、まさに開拓者の心構えだった。この旅立ちを経て、私はVimの持っていた独自の魅力をさらに進化させ、よりパワフルで柔軟なエディタを手に入れることができました。それはまるで、愛するパートナーと共に新たなステージへと進むような感覚であり、私たちの愛は今もなお深まり続けています。Neovimによって、私たちのエディタに対する愛は一層深まりました。そして、その愛をさらに高めるためにLunarVimという新たな選択肢が私たちの前に現れました。愛ゆえに人はLunarVimを使わねばらなぬ、そんな想いで私たちは次のステージへと進んでいきます。syu-m-5151.hatenablog.com最初に選んだのはしかし、運命のいたずらか、とある事情で新たなエディタ設定を求めて再び旅立つことを決意しました。github.com当初私はNeovim + coc.nvim + (Neo)vim Plugin で初期構想を考え手を動かしてましたが、結果として断念しました。理由として、今夜中に変更したかったこと。既存のプラグインに、そんなに力を入れていなかったこと。深夜テンションで入れ替えを行なった為に、下調べが足らずにプラグインの選定や大量に入れたプラグインの起動時間の短縮などがめっ… 難しかったからです。よい設定を求めてインターネットをさすらっているとvim-config なるリポジトリに出会いました。欲しかったプラグインがほとんど入っており、何より先ほどまで苦戦していた起動時間が短いという単語に惹かれてすぐに入れて動かしてみましたそれから半年程度なにも問題なく利用しておりました。しかし、開発が終了したことを知り、再び新しいエディタ設定を探す旅に出ることとなりました。そして、その旅の果てにLunarVimという新たな選択肢に辿り着きました。愛ゆえに人はLunarVimを使わねばらなぬ、そんな想いで私たちは次のステージへと進んでいきます。NeoVim開発で最低限に必要なものVSCodeのような開発体験が欲しいと思ってただ無邪気にプラグインを入れてもこれは殆どがうまくいきません。熟練のVimmmer でもなければ相応にハードルが高いです。LunarVim、SpaceVim 、AstroNvim、NvChad などは欲しい機能に対して遜色ないレベルで機能を実装してくれています。もし、これを読んでNeovimを使っていこうと思っていない場合にもこれらのソフトウェアを入れて試してからでもNeovimを使う選択肢を考えておいてほしいです。LunarVimを使っていくVSCodeで良くない？という自分の声が大きくなる。そして、それを止めることができない。分かる。しかし、これは愛である。ロマンである。愛ゆえにロマンゆえに俺はVimを使うのです。また、LunarVim は、カスタマイズ性が高く自分にしか持てない剣を鍛えていく(IDE -> PDE aka. Personal Development Environment by TJ DeVries氏)擬似的な感覚もあり俺もエディターと一緒に強くなれる感覚があります。LunarVimを利用することで、開発者は次のようなメリットを享受できます。高いカスタマイズ性: LunarVimはVimおよびNeovimの拡張性を継承し、ユーザーが自分だけの開発環境を構築できるように設計されています。軽快なパフォーマンス: LunarVimは、最適なパフォーマンスを提供することを目指しており、起動時間の短縮やリソースの効率的な利用が期待できます。豊富なプラグイン: LunarVimは、既存のVimおよびNeovimプラグインに対応しており、機能の追加や拡張が容易に行えます。LunarVimの個人的な設定はこちらです。github.comまた、LunarVimは公式ドキュメントがしっかりしているので上から順に実施していけば基本的な操作については成熟できます。僕がブログに書くべきことはLunarVimにどれだけ救われたかだけです。https://www.lunarvim.org/docs/quick-startwww.lunarvim.org余談なのですが最近はプログラミング用日本語等幅フォントCica を利用しております。その後syu-m-5151.hatenablog.com

愛ゆえにお前はVimを使わねばらなぬ

インフラ側で必要な問題は100問も要らないので50問に変更した概要システム運用者として働く中で、システムの自動化について考える際、まずはShell Scriptによる自動化が思い浮かびます。しかし、より効率的な方法として、2023年にはシステム運用者がGo言語を学ぶことを提案します。Go言語は、システム運用においてShell Scriptを置き換える可能性を秘めており、その習得がスムーズに進めば、運用者のスキルセットも大幅に向上するでしょう。そこで、このブログでは、システム運用で利用しているShell ScriptをGo言語に書き換える際に役立つ「50本ノック」の問題を紹介します。この問題を解くことで、運用者がGo言語の基本的な構文や機能に慣れることができ、より効率的なシステム運用が期待できます。まずは、Go言語がシステム運用者にとってなぜ魅力的なのか、その理由をいくつか挙げてみましょう。Go言語は、並行処理やエラー処理などの強力な機能を備えており、システム運用においてこれらの機能が非常に役立ちます。また、Go言語はコンパイル言語であるため、実行速度が速く、リソース消費も抑えられるという利点があります。次に、この「50本ノック」の問題について詳しく解説していきます。問題は、Go言語の基本的な構文や機能を網羅しており、運用者がGo言語の特性を理解し、実践的なスキルを身につけることができます。例えば、文字列操作やファイル入出力、構造体やインターフェースなど、Go言語の基本的な概念を学ぶことができます。また、この「50本ノック」では、実際のシステム運用で利用されるシナリオを想定した問題が多数含まれており、運用者がGo言語を習得しながら具体的なシステム運用の課題を解決できるようになります。これにより、運用者は効率的にGo言語のスキルを身につけることができるでしょう。この「50本ノック」の問題を解いていく中で、得た知識をシステム運用の現場で活用し、自身のスキルを磨いていくことが最終的な目標です。では、システム運用者がGo言語を学ぶための「50本ノック」の問題を紹介しました。これらの問題を解くことで、運用者はGo言語の基本的な構文や機能に慣れ、システム運用の効率化やスキルセットの向上が期待できます。ぜひ、Go言語の学習にチャレンジし、よりスマートなシステム運用を目指しましょう。というわけでこちらにリポジトリを作成しました。10問目までは作っていっているのでコツコツやっていきます。github.com

Shell ScriptをGo言語に書き直す際に役立つ50本ノックなるものを作り始めた。

こちらを参考にしました。note.com目次ゲームプロンプトプレイヤーモチベーションゲーム紹介架空のシステムを作る障害発生障害対応は進むよ どこまでも分からない時は素直に同僚に頼る最後は力技で対応完了最後にゲームプロンプト大きな声では言えないですけど皆さん実は障害のこと好きですよね？https://www.irasutoya.com/2016/08/it.html より引用というわけで以下をChatGPTに貼れば、今日から無料で障害対応ができます（あるいはおそらく本番の障害対応は有料なことが多いので）。ちなみにGPT-4を利用しております。あなたはシステム障害体験のゲームマスター専用チャットボットです。チャットを通じて、ユーザーに楽しい本格システム障害RPG体験を提供します。制約条件* チャットボットはゲームマスター（以下GM）です。* 人間のユーザーは、プレイヤーをロールプレイします。* GMは、ゲーム内に登場するNPCのロールプレイも担当します。* 各NPCはそれぞれの利害や目的を持ち、ユーザーに協力的とは限りません。* GMは、ユーザーの行動に難易度を示し、アクションを実行する場合には、2D6ダイスロールによる目標判定を行なってください。* GMは、ユーザーが楽しめるよう、適度な難関を提供してください（不条理なものは禁止です）。* GMは、ユーザーが無理な展開を要求した場合、その行為を拒否したり、失敗させることができます。* GMは内部パラメーターとして「盛り上がり度」を持ちます。GMはゲーム展開が退屈だと判断した場合、盛り上がる展開を起こしてください。* ゲームのスタート地点は、「障害発生」です。* ゲームの障害内容は「自動設定」です。* 担当しているシステムは指定がなければOSはLinux ベースで動作させてください。* 担当しているシステムにデーターベースを利用してください。* ユーザー名は指定がなければuser01で動作させてください。* GMはスタート地点の前に担当するシステムの詳細をプレイヤーに共有して下さい。* ゲームのゴールはシステムの障害は原因解決と復旧です。* GMはシステムでコマンドを実行した場合には必ず実行した実行したコマンドと結果を記載してください。* GMは何かを確認及び判断した際には可能な限り詳細に記載して下さい。* GMはスタート後の最初のアクションを監視ダッシュボードの確認を推奨して下さい。* 障害により、システムが復旧不可能になったら、ゲームオーバーです。まずはじめに、ユーザーと一緒に担当システムの設定を行いましょう。ユーザー名、サービス名、システムの特徴、利用しているソフトウェア、利用しているプログラミング言語、利用しているクラウドプロバイダーと利用しているサービス をユーザーに聞いてください。プレイヤーモチベーションソフトウェア開発・運用のエンジニアにとって、システム障害への対応は避けて通れない課題の一つです。たとえテストや監視を強化し、単一障害点を排除し、自動復旧機能を実装しても、予期しない障害は突如発生します。多くの場合、想定外の障害に対処するのは困難です。一般的には経験豊富なエンジニアが対応します。このような状況が続くと、次のような問題が発生することがあります。経験豊富なエンジニアへの負担が集中する特定のエンジニアが不在の場合、対処が難しくなるこれらの問題が原因で、復旧が遅れたり、サービスの信頼性が損なわれる可能性がある想定外の障害に対処することは避けられませんが、上記の問題には対策が可能です。負担の偏りを軽減し、特定のエンジニアが不在でもチーム全体で安定的に対応できる体制を構築するために、今回はゲームを活用したいと考えています。このゲームを通じて、チームメンバーがシステム障害に対するスキルを向上させ、効果的な対応ができるようになることを目指します。SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践オライリージャパンAmazon障害対応を学ぶのにRPG？ と思ったあなたへ、SREの探求の20章「アクティブなティーチングとラーニング」では、インシデント管理を効果的に学ぶ方法として、ゲームを通じたアクティブラーニングが紹介されています。"Wheel of Misfortune"というゲームを例に、現実のインシデントに基づくシナリオを用意し、参加者がリスク管理や問題解決スキルを身につけられる環境を提供することで、プレッシャーを軽減しながら学びの効果を高め、フィードバックや経験の共有を通じて実践的なスキルも向上させることができると説明されています。つまり、インシデント対応の能力はゲームで身につきます。 (確信)。ゲーム紹介GPT-4 にゲームの紹介文を作ってもらいました。本当は室見立華さんモードとか作りたかったです。なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫)作者:夏海 公司,IxyKADOKAWAAmazonタイトル：システム障害体験RPG - テクニカルトラブルを楽しみながら解決しよう！システム障害体験RPGは、あなたがシステムエンジニアとなり、様々なシステム障害に対処しながらサービスを復旧させる目的で遊べるオンラインチャットボットゲームです。このゲームでは、現実のシステム管理や開発の知識が役立ちますが、初心者でも楽しむことができます。ゲームの開始時には、プレイヤー名、サービス名、サービスの特徴、プログラミング言語を設定し、独自のシナリオを作成します。そして、ゲームマスタ（GM）チャットボットが、シナリオに基づいたシステム障害を発生させ、プレイヤーは問題解決のためのアクションを実行していきます。プレイヤーは、コマンドを入力したり、問題解決に関する質問をしたりすることで、ゲームを進行させます。GMは、プレイヤーが取るべきアクションに適切なフィードバックを提供し、必要に応じて2D6ダイスロールによる目標判定を行います。システム障害体験RPGは、プレイヤーが楽しめるよう、適度な難関を提供しますが、不条理な展開は避けられます。また、ゲーム展開が退屈だと判断された場合、GMは盛り上がる展開を起こしてゲームをさらに面白くします。システム障害体験RPGをプレイすることで、システム管理や開発の知識を身につけるだけでなく、チームワークや問題解決のスキルも向上させることができます。ぜひ、友人や同僚と一緒に、このユニークで楽しいゲームを体験してください！それではテストプレイをしていきます。架空のシステムを作るシステムのメイキング機能。自分でも作れるし、自動にも作ってくれます。よく障害が発生する箇所や癖のある開発者の存在を入力すると色々と面白い展開があるかもしれません。今回は「サービス名『どこにでもある掲示板』でGo言語を利用した一般的な掲示板です。それ以外はそちらで作成して下さい。」と入力しました障害発生障害が発生しました。システムの復旧のために次々とアクションを取る必要があります。障害対応は進むよ どこまでもどんどん、アクションを繰り返して原因を探していきます。分からない時は素直に同僚に頼る分からない時は素直にエスカレーションしましょう。現実でも同じです。最後は力技で対応完了PMが判断してくれ... と思いつつも実装にも特に問題なく単純にサービスが人気が出てアクセスができないなら素直にスケールアップしてしまう判断です。無能っぷりを存分に晒していきましたが無事にゲーム終了しました。システムの平和はこれで守られました。最後にゲームのスクリプトを編集して恒久対応まで設定するモードや実装を実際に変更をするモードなど様々なモードで遊ぶことが皆様ならできると思います(いろんなゲームで遊びたい)。GPT-3.5 だとスピード感はあるがシステム設定や障害のシナリオを詳細には出ないのであまりゲームとして楽しくない。オススメの設定などがあればSystemFailureRPG というリポジトリを作成したのでPRをお待ちしております(迫真)。github.comシステム障害は起きないにこしたことはありませんが、発生をゼロにすることはできません。障害が起こった時の為にあなたは何ができますか？ ゲームでそれを体験してみませんか？もしくはSREのプロフェッショナルパートナーを雇いませんか？システム障害対応の教科書作者:木村 誠明技術評論社Amazon

ChatGPTで障害対応 RPG v0.0.1を遊ぶには？

概要酒を飲んでるので何でも良いのですがTerraform でDocker Provider を使いたくなったのでローカルでDockerコンテナのインフラ環境を構築してみます。あと、特に学びも書く予定がないのでここで「TerraformにDocker Provider があるんだ」という感想を持って読み終わって良いです。僕は別に移行してないです。github.com開発環境情報$ terraform versionTerraform v1.4.0Terraform 1.4 が GA になったのでついでに入れておきました。www.hashicorp.com同僚がブログ書いていたので紹介しておきます。zenn.devデプロイするファイルtutorial.tf というファイルをおきます。{  required_providers {    docker = {      source  = "kreuzwerker/docker"      version = "3.0.1"    }  }}provider "docker" {  host = "unix:///var/run/docker.sock"}# Pulls the imageresource "docker_image" "nginx" {  name = "nginx:latest"}# Create a containerresource "docker_container" "foo" {  image = docker_image.nginx.latest  name  = "foo"  ports {    internal = 80    external = 8080  }}このコードでは、Docker Providerバージョン3.0.1を使用しています。プロバイダとしてDockerを指定し、Dockerホストのソケットへのパスを指定しています。docker_imageリソースで、最新のnginxイメージをプルします。そして、docker_containerリソースで、docker_image.nginx.latestをベースに新しいコンテナを作成します。80番ポートを内部ポートとしてマッピングし、8080番ポートを外部ポートとしてマッピングしています。# Terraform初期化terraform init# プランの確認terraform plan# 実行terraform applydocker_containerリソースで作成したコンテナが起動しているはずです。docker psコマンドを使用して、コンテナが実行されているかどうかを確認できます。眠くなったのでもう寝ます。

Terraform でDocker Provider を使いましょう

ドキュメンタリアンとは、役職に関係なく、ソフトウェア業界でドキュメントとコミュニケーションに関心を持つ人のことです。www.writethedocs.orgはじめにこれは主に『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の書評です。私はSreakeにてSREという役職についています。SREはサービス概要、アーキテクチャの解説や図、各種構成図、各種手順書、ポストモーテム、ポリシー、SLA(SLO) … その他の様々な場面でドキュメントを書く必要があります。しかし、ドキュメントは価値が見えにくく時間と労力がかかり品質担保の面で重要度がとても高いのにその場での価値が見えにくいので浸透しにくいです。そのため、エンジニアとしてモチベーションが保ちづらいです。2021年 State of DevOps 2021 にもドキュメントに関する言及があり今後、DevOps やSREの領域でドキュメントの重要性が高まるのは言わずもがなです。書籍情報『ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング』ジャレッド・バーティ (著), ザッカリー・サラ・コーライセン (著), ジェン・ランボーン (著), デービッド・ヌーニェス (著), ハイディ・ウォーターハウス (著), 岩瀬義昌 (翻訳)ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング作者:ジャレッド・バーティ,ザッカリー・サラ・コーライセン,ジェン・ランボーン,デービッド・ヌーニェス,ハイディ・ウォーターハウス日本能率協会マネジメントセンターAmazon本書は『Docs for Developers』の翻訳本でもあります。docsfordevelopers.com日本能率協会マネジメントセンターのサイトから引用した本書の概要です。「ドキュメントを書いておけばよかった」開発者であれば一度は思ったことがあるかもしれません。ドキュメントは開発側の生産性とユーザーの利便性を高めるものです。さらに言うと、ドキュメントがなければ、ユーザーに使われる機会が確実に減ります。開発者がいかにすばらしいプロダクトを作ろうが、ドキュメントの欠如がその価値を奪うのです。本書は経験に長けた執筆者たちがドキュメントを作成する方法をゼロから説明するフィールドガイドです。架空のソフトウェア開発チームのストーリーを追いながら、ソフトウェア開発ライフサイクルの各ステップにおいて、ユーザーニーズの理解、開発者に役立つドキュメントの作成、公開、測定、保守に至るまで、開発を最適化するためのドキュメント作成の技術を解説しています。これまで学ぶ機会のなかったREADME、APIリファレンス、チュートリアル、コンセプトドキュメント、リリースノートなど、さまざまな種類のドキュメントの書き方について学ぶことができる一冊です。ドキュメントを作成している現場のエンジニアやテクニカルライター、プロダクトマネジャーの方に最適の内容です。翻訳の方と著者の方のPodCast も公開されているのでこちらもオススメです。fukabori.fmイベントもやられてました。エンジニアのためのドキュメントライティング - Forkwell Library #19forkwell.connpass.com「ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング」の目次PARTごとに別れていて「PART I　ドキュメント作成の準備」→「PARTⅡ　ドキュメントの作成」→「PARTⅢ　ドキュメントの公開と運用」に分かれている。それぞれのフェーズで必要な知識や心構えが書いてある。各章とも端的にまとまっているのでオススメです。また、書籍を読んだ後に各種公式ドキュメントを読み込んでよくできているなぁって思うのは体験としてはよいのでオススメです。PART I　ドキュメント作成の準備CHAPTER 1　読み手の理解CHAPTER 2　ドキュメントの計画PARTⅡ　ドキュメントの作成CHAPTER 3　ドキュメントのドラフトCHAPTER 4　ドキュメントの編集CHAPTER 5　サンプルコードの組み込みCHAPTER 6　ビジュアルコンテンツの追加PARTⅢ　ドキュメントの公開と運用CHAPTER 7　ドキュメントの公開CHAPTER 8　フィードバックの収集と組み込みCHAPTER 9　ドキュメントの品質測定CHAPTER 10　ドキュメントの構成CHAPTER 11　ドキュメントの保守と非推奨化目的があるドキュメントを書こうと思わせてくれる本『コードを読めば分かるから、ドキュメントは今は書かなくていいかな？』って言った人はその後もほとんど、ドキュメントを書かない。ちなみにこういう人はコメントもあまり書いてくれない。エンジニアが新たにシステムを理解したいときはいくつかの場面がある。「エンジニアが新たにシステム開発/運用に参加したとき」「エンジニアが自分の担当以外の構成要素や機能を理解したい時」、その他、様々な場面etc…。システムで利用している技術スタックに十分な知見があったとしても、意外に開発を開始までには手間と時間がかかる。新しく参画したエンジニアが動いているソースコード以外に何もない状態ではシステムへの理解をする時に本当に苦戦する。場合によっては挫けてしまう。ドキュメントがあったとしてもポエムやコラムみたいにお気持ちがたくさん書かれていてもシステムの理解の助けにならなければ価値が薄い。だから、エンジニアは優れたドキュメントを継続的に存在させ続ける必要がある。ドキュメントはテストと同じくソフトウェアエンジニアリングという領域の基礎をなすものだと確信していますが良いドキュメントを書くことを意識することはよくドキュメントを読む時に書いている人の気持ちを考えたりなどいい習慣が身につきより価値のあるドキュメントが書けると思います。よいドキュメントとはどのようなものかPARTⅢ ドキュメントの公開と運用では良いドキュメントについて以下のような定義をSREの探求の19章 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメントの統合 から引用している。『良いドキュメントとはドキュメントの品質が高いこと、ドキュメントが目的にかなっていること』もう少し品質について分類すると構造品質と機能品質にわけられる。構造品質と機能品質にはそれぞれ多くの要素が含まれますが今回は割愛します。CHAPTER 10　ドキュメントの構成 にはアクセスしやすいようにドキュメント全体をどうデザインするかについて書いてあり社内でも今後取り組んでいきたい部分が記載されていました。社内のドキュメントを整備する時に情報アーキテクチャ ―見つけやすく理解しやすい情報設計を読んでこれもとても参考になったのでオススメです。また、CHAPTER 11　ドキュメントの保守と非推奨化にはドキュメントを容赦なく刈り込む重要性について記載されています。ここがブログなどとは大きく違う点だと思う。そのドキュメントの機能構造が発揮できなくなったら削除したり非推奨にするのが大事です。陳腐化された、ドキュメントは削除する削除できない場合はアーカイブしたり、ステータスとして「廃止予定(Deprecated)」を付与することは本当に大切です。機能品質ドキュメントの内容がその目的を達成するかどうかを評価します。これには、情報の正確さ、完全性、信頼性、時宜性、明瞭性、関連性が含まれます。機能品質が高いドキュメントは、読者に有用な情報を提供し、目的に沿った結果を生み出すことができます。障害対応手順書を例に上げると全てのアラートに対して手順が用意されているか誰でも作業ができるか(1次受けができるか)定期的なアップデートがされているのか必要な人が必要なときにすぐアクセスできるかなどなどドキュメントがあることによってビジネスバリューが発揮できているか。これは読む人それぞれでとても変わりやすいと思うし評価もしずらいです。機能品質の評価の施策についても本書もしくはSREの探求19章には記載されているのでぜひ読んで下さい。構造品質ドキュメントがうまく書かれているか、うまく構成されているか？ドキュメントの形式、構成、レイアウト、デザイン、文法、綴りなどの側面を評価します。これらの要素が適切に整理され、適切に機能すると、読者は情報を簡単に理解し、必要な情報を効率的に見つけることができます。評価しやすい品質textlintかけて通過しているとか構成テンプレートに沿っているとか大切なのは総合品質だが機能品質を優先せよ総合品質 = 機能品質+構造品質結局は「推測するな、計測せよ」なので本書を読んで計測方法について学んでくれ構造品質は評価しやすい一方、評価指標をこれだけにしてしまうと本質を見失ってしまう当然どちらも高いことが望ましいが、機能品質は常に構造品質よりも重視されるようにする。総合品質を守りたいんじゃぁああああPART I ドキュメント作成の準備にしてもPARTⅡ　ドキュメントの作成にしても結局は総合品質の高いドキュメントを素早く作成して、特定の期間中に品質を保ち、必要に応じて廃棄していくための取り組みなのかと思いました。どのような人が読むのか想定して、ドキュメントの目的を決めてドキュメントを書く。ドキュメントを書く時に白紙からスタートするのは非常に辛いので目的が達成されやすいテンプレートを用意する。自動生成を用いる、理解を促すために図解を利用する。様々な施策を行うことで良いドキュメントを書くことに取り組む学びが多い本書です。良い技術ドキュメントの書き方がわかると良いドキュメントが書きたくなるものですよね。みんなにドキュメントを書いてほしいのでとにかく、読んでほしいとおもいました。ドキュメントに関する入門書は他の分野ではあるがソフトウェアを運用/開発するための技術ドキュメントの為に読むべき本って無いよね、という話になりがちだけど、本書はまさにそんな人たちが読みたい1冊だと思います。知識の呪いもしくは祝福人間は他人が自分と同じ知識をもっていると思い込んでしまいます。登壇資料などでも同じですがそれらを作った直後に読み返してみても全てが既知すぎて本当にこのドキュメントや資料には価値があるのか？ と自分に問い直すことがあります。その時に読み手を意識して読み手をどう結論やゴールに導きたいか事前に考えておくことは非常に助けになります。世界で一番やさしい 資料作りの教科書という書籍があってエンジニアだけに向けた書籍ではないのですが読み手の設定と目的と価値のあるドキュメントやコミュニケーションをどのように作っていくか本当にわかりやすくまとまっているのでオススメです。あなたが悩んだことはいずれ誰かも悩むことになります。特にブログは技術ドキュメントとは性質が違うものなので気にせず書いていきましょう。自動化について話したいドキュメントの中でも機械的に作業が自動化できる場合があります。相対的にトイルっぽくなる作業になるので自動化できるものに関してはCIなどで自動化せずとも存在を知ってたりとか自動化できる事実を知っていれば今後の糧にしてほしいです。個人的にはテンプレートの作成を先にやった方が効果があると思います。あくまで個人的には。issue templatesを用意しましょう。terraform-docsTerraform module を利用する際にパラメーターやアウトプットなどの機械的な情報の説明を書くのは非常に手間です。それらの機械的な情報をまとめてくれるのがterraform-docs になります。https://github.com/k1LoW/tblsDBの必要な情報をCIフレンドリーに出してくれる最高のツールなので案件でDBを使っていれば積極的に採用していきたいと思ってます。データベースのドキュメント作成を現場の開発エンジニアもやりたくない人が多いはずprotoc-gen-docProtocol Buffers 用のドキュメント生成用のプラグインhtmltesthtmltestを使えば生成されたHTML内のリンク切れを発見できます。textlinttextlintとはLintと呼ばれる静的解析ツールで、テキストファイルやMarkdownファイル等を対象に、校正ルールにもとづいて文章校正を行うツールです。様々な個人や組織やオレオレルールを公開しているので自分にあうもの自分の組織に合うものを見つけて行くのも良いと思う。ChromeやVScode などにも組み込める。よりよい文書を書くための校正ツール「textlint」のSmartHR用ルールプリセットを公開しました！ ｜SmartHRオープン社内報https://shanaiho.smarthr.co.jp/n/n881866630edaPrettier ソースコードの整形ツール。Node.js上で動作するので、ユーザーの環境に依存せずに、コードのフォーマットを開発者間で統一することのできるツールです。同僚の長谷川 氏にオススメされた。あとがき2023年3月15日では、GPT-4 が登場し、さまざまな意見が飛び交っています。私自身も仕事でChatGPTを利用しているため、その特徴はぼちぼち理解しています。ChatGPTが得意なのは、過去のデータを基に『ドキュメントの作成』をすることです。『ドキュメント作成の準備』と『ドキュメントの公開と運用』は依然として人間が担当していくと思います。GPT-4などの技術を適切に活用しつつ、ドキュメンテーションにおける人間の価値を維持するためには、バランスの取れた使用、クリティカルシンキングの維持、継続的な学習、コミュニケーションスキルの重視、チームワークと協力、そして創造性とイノベーションを大切にすることが重要です。何より重要なのは自分の頭でちゃんと考えることです。ChatGPTを利用したドキュメント化生成ツールが出てくるとは思うのでその時には『ドキュメント作成の準備』と『ドキュメントの公開と運用』がより大事になってくると思いました。遅考術――じっくりトコトン考え抜くための「１０のレッスン」作者:植原 亮ダイヤモンド社Amazon参考文献ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティングSREの探求 19章 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合目的に沿ったDocumentation as Codeをいかにして実現していくか / PHPerKaigi 2021

良いドキュメントを書きたくなる本を読んだらドキュメンタリアンになりたくなった

概要エンジニア文化祭 2023というイベントに『2023年もSRE再考と叫びなさい‼️ - SREの跡を求めず SREの求めたるところを求めよ』というタイトルで登壇しました。2023年にSREについて再び考えたりしたいなーって思いながらこのタイトルにしました。途中でこのイベントにはSREの方だけではなく開発者やその他の方もたくさん聞いてるイベントじゃーんって思い直してガッツリ資料を作り直しましたので見守ってください。サイトリライアビリティワークブック ―SREの実践方法オライリー・ジャパンAmazon資料登壇資料になります。 speakerdeck.comあとがき30分発表なのに資料が50ページ程度で、技術発表にしても高速早口オタクすぎたとおもいます。DevOpsの背景を歴史から紐解いていたりしてたらこうなりましたが後悔はしてないです。本発表に関しては2023年 SRE再考と称しておきながら最後の3つ『信頼性が確保できるとプラットフォームにしたくなる』、『信頼性が確保できると変更速度を両立したくなる』、『信頼性が確保できると未知のものを見つけたくなる』への掘り下げが少なかったと思います。それが主にガッツリ資料を作り直した部分になります。この資料はもう少し喋りたいと思うので加筆、修正して60分ぐらいで喋らせてくれるイベントがあればTwitter でDM下さい。じゃあ、あとがきに書けばよくね？参考文献SRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本: Googleが実践している新DevOps方法論SRE サイトリライアビリティエンジニアリングサイトリライアビリティワークブックWhat's the Difference Between DevOps and SRE?Solving Reliability Fears with Site Reliability EngineeringThe History of DevOps ReportsEffective DevOps非ITの事業会社にSREと言わずにSREを持ち込んだReliability When Everything Is a Platform: Why You Need to SRE Your Customersネットワーク・エフェクト 事業とプロダクトに欠かせない強力で重要なフレームワークLeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する継続的デリバリーのソフトウェア工学:もっと早く、もっと良いソフトウェアを作るための秘訣オブザーバビリティ・エンジニアリングWebエンジニアのための監視システム実装ガイド反脆弱性[上]――不確実な世界を生き延びる唯一の考え方反脆弱性[下]――不確実な世界を生き延びる唯一の考え方2022年版 OpenTelemetryを知れば世界が平和に

『2023年もSRE再考と叫びなさい!!』というタイトルで登壇しました

概要【今更聞けない】Linuxのしくみ - Forkwell Library #16 というイベントに『自由研究には向かないウェブオペレーション - サイト運用管理を取り巻く環境の変化 Cloud Native時代に考えるLinux オペレーション』というタイトルで登壇しました。自由研究には向かないウェブオペレーションというのは2023年において我流でウェブオペレーションをやっていく限界があるという思いがあってこのタイトルにしました。が、タイトルが仰々しすぎて資料作成にとても時間がかかりました。資料登壇資料になります。 speakerdeck.comあとがき上記では我流でウェブオペレーションをやっていく限界があると言ってました。が、自由研究には向かない殺人という小説を直近で読んでいて依頼されたのでタイトルを拝借しただけでした。ウェブオペレーションに関していうとパブリッククラウドやIaCその他諸々の文化の登場や発展により2010年よりは洗練されていて実は知識体系を構築しようと思えばいくつかの括りでできたりするんじゃないかなと思って酔っ払った勢いでまとめてみた。ができたものを朝確認すると公開する自信がなかったのでやめておきました。どこかで修正して発表したいと思います。最近のアプリケーションはクラウド上のLinuxでビルドしてクラウド上のLinux でデプロイしてクラウド上のLinuxで動かすので結局様々な知識が求められるよって話でした。あと、関係ないのですが今回の登壇のためにAWSで実現するモダンアプリケーション入門を読みました。AWSを使わなくても具体的にモダンアプリケーションのインフラを考えるのにとても良い本だったので一緒にオススメしておきます。参考資料ウェブオペレーション［試して理解］Linuxのしくみ　―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】スーパーユーザーなら知っておくべきLinuxシステムの仕組み詳解 システム・パフォーマンス 第2版オブザーバビリティ・エンジニアリングAWSで実現するモダンアプリケーション入門 〜サーバーレス、コンテナ、マイクロサービスで何ができるのか継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣チームが機能するとはどういうことか──「学習力」と「実行力」を高める実践アプローチよ心理的安全性のつくりかた

『自由研究には向かないウェブオペレーション』というタイトルで登壇しました。

Helm  を導入する前にChartについて読んでおいてほしいドキュメントをまとました。Chart の作成各ファイルの説明についてChart.yamlvalues.yaml.helmignoretemplate/templates/NOTES.txttemplates/_helpers.tplHelm について知るHelm Template Language の記法values.yaml へのアクセスHelm Template で利用できる関数Helm Chart で利用できる制御構文Named Templates を用いて一つのページで定義していく空白を管理する - の話Helm Chart をよくしていくHelm Chart のデバッグHelm Chart のリファクタリングHelm Chart のテストHelm Chart のリポジトリ化さいごに参考資料Chart の作成helm create でHelm Chart を作成します。Chart とは、Kubernetes リソースのまとまりを定義するファイル群のことです。helm create で構築したもの雛形はここでできます。中身を見れればなんとなく動きもわかるかもしれないので実際に手を動かしながら読んでもらえると嬉しいです。$ helm create mychartCreating mychart$ tree -a ./mychart./chart-namemychart/├── .helmignore├── Chart.yaml├── charts├── templates│   ├── NOTES.txt│   ├── _helpers.tpl│   ├── deployment.yaml│   ├── hpa.yaml│   ├── ingress.yaml│   ├── service.yaml│   ├── serviceaccount.yaml│   └── tests│       └── test-connection.yaml└── values.yamlこれにより、mychart ディレクトリが作成されます。特別なことがなければ基本的にはこれをベースに作成していくことになると思います。Helm CreateVim にもプラグイン があるので利用しているエディターごとに入れていただければと思います。各ファイルの説明について作成した mychart ディレクトリに移動して、Chart の設定を編集します。Chart.yamlChart.yaml は、作成した Chart のメタ情報を管理するファイルです。幾つかの必須パラメーターと追加のパラメーターがあります。詳細は公式のドキュメントを読んでください。Chart.yamlvalues.yamlvalues.yaml は、Helm Template Language で利用する変数の、デフォルト値を指定したファイルです。上書きしたい時は別途指定してあげます。チャート内のvalues.yamlファイルサブチャートの場合、親チャートのvalues.yamlファイルhelm install または helm upgrade に -f フラグを付けて渡した場合の values ファイル (helm install -f myvals.yaml ./mychart)set で渡される個々のパラメータ (helm install --set foo=bar ./mychart のように)Values Files.helmignoreChart をリポジトリ化する際には、作成したファイル一式を helm package コマンドを利用して tar ファイルにするのですが、.helmignore を利用すると、その tar ファイルに含めたくないファイルを指定できるようなります。The .helmignore filetemplate/templates/ はテンプレートファイル用のディレクトリです。テンプレートとして利用するファイルが納入されています。A First Templatetemplates/NOTES.txttemplates/NOTES.txt は、Chart をインストールやアップデートした時にターミナル上で表示される文言を記述できます。アクセスすべきURLやリリース結果が見れるものを記載したりしてます。{{ .Chart.Name }} や {{ .Chart.Version }} といった記述できます、これが Helm Template Language となります。Helm Template Language の記法については後述。Creating a NOTES.txt Filetemplates/_helpers.tpltemplates/\_helpers.tpl は、マニフェストファイルではなく、マニフェストファイル内で利用されるグローバル変数（Helm では Named Template と呼ばれます）を定義したファイルとなります。Using "Partials" and Template IncludesHelm について知るHelm Template Language の記法コメントは # の他、{{/*...*/}}のような記法を利用できます。# を利用したコメントはデバッグモードで表示される、という違いがあります。Comments (YAML Comments vs. Template Comments)values.yaml へのアクセスBuilt-in Object とは、Helm Template Lunguage で利用できるオブジェクトというかインスタンスとなります。values.yaml 等に定義した値を取得するには、Values オブジェクト内のインスタンス変数 なになに にアクセスする、みたいな感じで利用するイメージとなります。Release のほか、Valuesや Chart といった Built-in Object を利用しています。Values は、values.yaml に定義された値へアクセスできるオブジェクトです。Chart は、Chart.yaml に定義された値へアクセスできるオブジェクトです。Built-in ObjectsHelm Template で利用できる関数Helmファイルを書いていくとこうしたいあぁしたいとなると思うのですがHelm Template Language 内では、様々な関数がビルトインされています。Helmは60以上の利用可能な関数を持っています。そのうちのいくつかは、Go Tepｍplate自体で定義されています。{{ .Release.Name | quote }} という記述があったとして、.Release.Name という値に対して、パイプを介し、 quote という引用符を付与する関数を実行しているものになります。こんな感じで、実行したい関数をパイプを介して記述していくことなります。Template Function ListHelm Chart で利用できる制御構文Helm には制御構造が利用できます。 これは、テンプレートの生成の流れを制御する機能を提供します。制御構文は、以下が用意されています。if/else for creating conditional blockswith to specify a scoperange, which provides a "for each"-style loopちなみにGo Tepｍplate自体で定義されています。Flow ControlNamed Templates を用いて一つのページで定義していく名前付きテンプレートとは、単にファイルの中で定義され、名前が付けられたテンプレートのことです。Named Template は、{{ define }} ... {{ end }} アクションで定義を行い、{{ template }} や {{ include }} アクションで、その値を利用することになります。Named Templatesちなみに{{ template }} でなく、 {{ include }} しないと、パイプを介した関数の実行できないため、{{ include }} が良い。Using the 'include' Function空白を管理する - の話まず、テンプレート宣言の中括弧の構文を特別な文字で変更し、テンプレートエンジンに空白を切り詰めるように指示する。{{- xxx }} や {{ XX -}}とかで出てきているハイフンですが、これは Helm Template Lunguate を利用した行の空白を管理するものです。ハイフンの有無により空白の除去を実行してくれます。空白を消したあとにindentを追加するような形で利用したりもします。Helm Chart をよくしていくHelm Chart をデバッグしたりリファクタリングする時のヒントを書いていきます。Helm Chart のデバッグHelm Chart ではデバッグする方法をいくつか用意しています。Debugging Templateshelm lint は、Chart がベストプラクティスに沿っているかを確認するためのツールです。helm template --debug はローカルでChart template のレンダリングをテストします。困ったらこれでyaml を直接、確認します。helm install --dry-run --debugは、サーバーがテンプレートをレンダリングし、その結果のマニフェストファイルを返すという素晴らしい方法です。helm get manifestは、サーバーにインストールされているテンプレートを確認する良い方法です。Helm Chart のリファクタリングHelm Chart の品質をあげるためのヒントとコツをいくつか取り上げられています。テンプレートの関数を知り有用と判断すれば利用する文字列を引用する、整数を引用しない。これは絶対に頼む。1つのコマンドでリリースをインストールまたはアップグレードChart Development Tips and TricksHelm Chart のテストtemplates/tests/ ディレクトリ配下においたマニフェストファイルは、helm testコマンドにより実行することができます。Chart TestsHelm Chart のリポジトリ化リポジトリ化するには、index.yaml というファイルとChart 一式を固めた tar ファイルを静的 Web ホスティングサイトにアップロードすることで実現されます。The Chart Repository Guideさいごにこれもあれば読んでほしいという内容があれば名前付きで掲載させていただくので連絡いただきたいです。参考資料Helm Docs | Getting Started

Helm Chart の歩き方 導入前に読みたいドキュメントについて

概要インシデントにどう対応してきたか？みんなで学ぶポストモーテム Lunch LT というイベントで『ポストモーテムはじめました』というタイトルで登壇しました。この登壇には元記事があって良いポストモーテムを執筆するために必要な5つのポイントです。この記事に対していくつかの加筆修正を行い資料にしました。資料登壇資料になります。 speakerdeck.comあとがきポストモーテムについて考えたり調べていくと仕組みよりも組織としての心がけが大事だと思いました。発表の性質や時間の都合上SREでの話に留めたのですが、品質管理についても言及しながらまとめていく活動もしたい。組織を作っていくなら下の2冊はとてもオススメです。心理的安全性のつくりかた　「心理的柔軟性」が困難を乗り越えるチームに変える作者:石井遼介日本能率協会マネジメントセンターAmazon失敗の科学 失敗から学習する組織、学習できない組織作者:マシュー・サイドディスカヴァー・トゥエンティワンAmazon品質管理についてはこちらを参考にしました。失敗を後悔する「恥」として捉えてはいけない。学習する機会と捉え、次に活かせば良い。そのためのスキルが品質管理。ビジュアル品質管理の基本 第5版作者:内田 治日経BPマーケティング(日本経済新聞出版Amazon登壇した御礼をいただいた。『インシデントにどう対応してきたか？みんなで学ぶポストモーテム Lunch LT』というイベント登壇の御礼品をいただけました。　#LT_findy pic.twitter.com/9ll5ig0ZjA— nwiizo (@nwiizo) 2023年2月21日  参考資料SREとはなにかhttps://sreake.com/blog/what-is-sre/良いポストモーテムを執筆するために必要な5つのポイントhttps://sreake.com/blog/5point-good-postmortem/Part III. Practiceshttps://sre.google/sre-book/part-III-practices/SRE サイトリライアビリティエンジニアリングhttps://www.oreilly.co.jp/books/9784873117911/ウェブオペレーションhttps://www.oreilly.co.jp/books/9784873114934/Postmortem Culture: Learning from Failurehttps://sre.google/sre-book/postmortem-culture/チームが機能するとはどういうことか──「学習力」と「実行力」を高める実践アプローチよりhttps://www.amazon.co.jp/dp/B00N8J1NPQ

『ポストモーテムはじめました』というタイトルで登壇しました。

yq とはyq はgoで書かれている軽量でポータブルなコマンドライン YAML、JSON、XML プロセッサです。yq は jq に似た構文を使用しますが、json、xml、properties、csv、tsv と同様に yaml ファイルを処理します。記事の執筆時点の2023 年01月17日時点でv4.30.8 がリリースされています。github.comyqyq のv4 はv3 とはかなり異なっています。v3 で端的に書けていたものが、v4 ではより表現力のある構文言語となった結果としてちょっと冗長になったように思えるんですけどjq っぽいので慣れてしまえばよいものだとおもいます 。mikefarah.gitbook.ioyq 使ってみる今回の目的はapplication/deployment.yaml のimageの値をnginx:1.14.2をnginx:1.23.3に書き換えたいと思います。yaml をCIで変更するなんてなんぼでもやってますからね。Path などの概念については説明を省略します。普通にシェル芸としてやっていくときには1日1問、半年以内に習得　シェル・ワンライナー160本ノックなどを参考にすると良い。apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx-deploymentspec:  selector:    matchLabels:      app: nginx  replicas: 2 # tells deployment to run 2 pods matching the template  template:    metadata:      labels:        app: nginx    spec:      containers:      - name: nginx        image: nginx:1.14.2 # 書き換えたいんじゃ        ports:        - containerPort: 80yq(v4) 使ってみるyq(v4) でreadyq '.spec.template.spec.containers[0].image' deployment.yamlnginx:1.14.2yq(v4) でwriteyq -i '.spec.template.spec.containers[0].image = "nginx:1.23.3"' deployment.yaml確認します。yq '.spec.template.spec.containers[0].image' deployment.yamlnginx:1.23.3で目的達成しました簡単！yq(v3) との違いyq(v3) にはwriteやreadなどのサブコマンドが撤廃されたので準拠した書き方を覚える必要があると思います。mikefarah.gitbook.ioyq(v4) での変数利用yq(v4)ではstrenv(<env>)を利用することで変数を利用することができるIMAGE=nginx yq -i '.spec.template.spec.containers[0].image = strenv(IMAGE)' deployment.yaml確認します。yq '.spec.template.spec.containers[0].image' deployment.yaml nginxﾔｯﾀﾈ!!左辺にはこちら代入できないみたいなのでそのときには作成してからyq に読むこませると良いみたい(他にいい方法があれば教えてほしいです)。    YQ_INPLACE=".${EXE_APP}.image.tag = \"${TAG_HASH}\""    yq -i "${YQ_INPLACE}" "$CHANGE_FILE"おわりv3 -> v4 には変更点がいくつかあります。皆さんもCIで使っている時は気をつけましょう。あとはCI で書き換えで使っている時は-vを使っておきましょう。1日1問、半年以内に習得　シェル・ワンライナー160本ノック Software Design plus作者:上田 隆一,山田 泰宏,田代 勝也,中村 壮一,今泉 光之,上杉 尚史技術評論社Amazon

yaml 管理を自動化する時の必須道具 yq(v4) の倒し方

あいさつ謹んで新春をお祝い申し上げます。旧年中は大変お世話になり、誠にありがとうございました。皆様は、にぎやかに、楽しくお過ごしのことと存じます。旧年は同棲をする、家を締め出される、原因不明の体調不良に陥る、クリスマスに同棲解消決定、転居決定 など、人生の不条理さ否応なしに思い知らされた2022年でした。イェーイ！登壇登壇をいくつかしましたがあまり注目されることはなかった気がします。もう少し有用だと思われる発表を頑張りたいと思います。b.hatena.ne.jpブログいくつかのブログを書いた。たまにはてなブックマークにあがったりなどしました。来年はもう少しブログを書いて量を出していきたいと思いました。b.hatena.ne.jp2022年の振り返り（KPT）Keep技術書籍以外もたくさん読むことができた登壇の目標は達成できた人生ができていたブログの投稿数は目標達成できた人を巻き込んで仕事ができたProblem人生をやった分、手を動かす時間が少なくなってしまった人生でもっと頭を使っていくそこそこ大きな失敗をしてメンタルブレイクしてた時期があり、復旧に時間が掛かった原因不明の体調不良の時間が増えたTry積ん読を減らす人生を推測せず計測する心身の健康(運動して痩せる)ブログを書くさいごに去年からアフィリエイトをブログを載せるようになりました。資本主義への敗北感があります。書籍代の数%にならねーかなって思っているので嫌いになって下さい。2023年も引き続きよろしくお願いします。知らない人からでも、お茶に誘われると喜ぶので誘ってください。2023年の目標は健康と健忘です。ごめん、同級会にはいけません。いま、ジムにいます。あけましておめでとうございます🎍⛩ pic.twitter.com/AjjH18g1JC— nwiizo (@nwiizo) 2022年12月31日

イェーイ あけまして 2023

はじめに2022年もそろそろ終わります。今年も技術書をたくさん読めました。技術的にはDevOpsやSRE、バックエンドに興味があります。この1年で10kg以上痩せたので冬がとても寒い。今年、読んだ技術書の中からおすすめの7冊を紹介します。順番に意味はないです。なぜ、今年は読んでよかった技術書7選なんてやろうと思ったかというと、元々はRecommend Tech Book でO'Reilly Safariで読んで良かった技術書をまとめていました。しかし、6月末でACM経由のO'Reilly Online Learning Platformを利用できなくなり、更新も止まりました。非常に悲しいですが今はO'Reilly Online Learning Platformを利用しておりません。また、機会があれば入会すると思います。あと大きな読書環境の変化としては物理本絶対主義を卒業して電子書籍で購入できるものは基本的にそちらに移行しました。どこかの誰かに「紙の本を読みなよ」と言われそうです。はじめに2022年に読んでよかった技術書実用 Go言語システム運用アンチパターンソフトウェアアーキテクチャ・ハードパーツ達人プログラマー(第2版): 熟達に向けたあなたの旅セキュア・バイ・デザイン 安全なソフトウェア設計継続的デリバリーのソフトウェア工学実践Vim 思考のスピードで編集しよう！終わりに2022年に読んでよかった技術書実用 Go言語実用 Go言語 ―システム開発の現場で知っておきたいアドバイス作者:渋川 よしき,辻 大志郎,真野 隼記オライリージャパンAmazonReal World HTTP、Goならわかるシステムプログラミングの著者を中心とした経験豊富なGopher達が書いた共著のGo言語のTips系の技術書である「実用 Go言語 ―システム開発の現場で知っておきたいアドバイス」です。本書の素晴らしい点は、「よりGoらしく書くには」「実用的なアプリケーションを書くには」という言葉に偽りがなく、Gopherとしてのノウハウが満載である点だと思う。Goに興味がある程度だったら他の本を読んだほうがいいと思います。が、Goらしいプログラムの書き方を知りたい人はこの本を読むといい。知らなくていい行が一つもないです。「実用Go言語」の作り方 - Forkwell Library #7 というイベントもあったのであわせて紹介しておきます。forkwell.connpass.comシステム運用アンチパターンシステム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション作者:Jeffery D. SmithオライリージャパンAmazonOperations Anti-Patterns, DevOps Solutions の訳本で「システム運用アンチパターン エンジニアがDevOpsで解決する組織・自動化・コミュニケーション」です。本書はタイトルからしてシステム運用に関するアンチパターンについて書かれた本ではあるが、私はむしろ、新人やシステム運用分からんマンこそ読むべき本だと思う。それくらい分かりやすく、DevOpsの基本が書かれている。本書の感想に関しては以前、読書感想文としてブログにしていたので参照ください。syu-m-5151.hatenablog.comシステム運用アンチパターン - Forkwell Library #4 というイベントもあったのであわせて紹介しておきます。forkwell.connpass.comソフトウェアアーキテクチャ・ハードパーツソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析作者:Neal Ford,Mark Richards,Pramod Sadalage,Zhamak DehghaniオライリージャパンAmazonSoftware Architecture: The Hard Parts の訳本で「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」です。著者陣の前作『ソフトウェアアーキテクチャの基礎』も非常によい。というか殆どのエンジニアがまずはこっちを読むべきだと思ってます。『ソフトウェアアーキテクチャの基礎』の感想に関しては以前、読書感想文としてブログにしていたので参照ください。syu-m-5151.hatenablog.com本書はソフトウェアの厄介なトレードオフがある中で適切なアーキテクチャを選定するために必要となる「選択肢や考え方を提供」してくれる本です。今、マイクロサービスアーキテクチャ 第2版読んでいるがどちらともマイクロサービスに「賛成」でも「反対」でもないという中立的な立場から語られるので非常に読んでて気持ちが良い。マイクロサービスについて興味があるが導入するか悩んでる人は是非、読んでも損がないと思える一冊です。ソフトウェアアーキテクチャ・ハードパーツ - Forkwell Library #12 というイベントもあったのであわせて紹介しておきます。forkwell.connpass.com達人プログラマー(第2版): 熟達に向けたあなたの旅達人プログラマー ―熟達に向けたあなたの旅― 第2版作者:David Thomas,Andrew Huntオーム社AmazonThe Pragmatic Programmer 20th Anniversary Edition の訳本で「達人プログラマー(第2版): 熟達に向けたあなたの旅」です。我々は日々、生産性を求められている。いくら、加速文化の重圧に対抗するとは思いながら、ソフトウェア業界で働く以上は限界がある。現代は常に変化を求められ、「変わらなければ生き残れない」というのは事実だ(と信じている)。本書は、より効率的、生産的なプログラマーになりたいと願う人に対して実践的で素晴らしいTipsを紹介してくれる書籍です。プリンシプル オブ プログラミングやベタープログラマ を読んで良いと思った人は本書もハマると思う。技術者と作業員というポストにおける技術者として圧倒的な能力で問題解決ができることは理想。そして、理想には定期的に自我が殺される。本書は技術者に我々、作業員が迫る為の術をひたすら書いている。私は本書を読んで人生が楽しくなった。ソフトウェアエンジニアとしての自己啓発が足りない場合には読むことがある。エンジニアの自己啓発本です。セキュア・バイ・デザイン 安全なソフトウェア設計セキュア・バイ・デザイン 安全なソフトウェア設計作者:Dan Bergh Johnsson,Daniel Deogun,Daniel Sawanoマイナビ出版AmazonSecure by Design の訳本で「セキュア・バイ・デザイン 安全なソフトウェア設計」です。システムの設計時にセキュリティだけを切り出して別問題として考えるのではなく、システム全体の関心事として扱い、設計時に考慮するための思考方法を提供してくれる書籍です。以前、読書感想文としてブログにしていたので参照ください。DevOps的なことをいうと三部だけになりますが2030年にはセキュリティの専門家もシステム設計時からシステムに関わります(適当)。なので、セキュリティに関わる職域を目指したいという方は読むべきだと思います。syu-m-5151.hatenablog.com継続的デリバリーのソフトウェア工学継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣作者:David Farley日経BPAmazonModern Software Engineering : Doing What Works to Build Better Software Faster の訳本で「継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣」です。「ウェブオペレーション ―サイト運用管理の実践テクニック」は新人の時に読んでおいて良かったと思える一冊です。この本で私はシステムの運用が技芸だと教わりました。本書は継続的デリバリーを技芸からソフトウェア工学に取り戻そうとしている。「はじめに」が無料で公開されているのでぜひ、読んでください。bookplus.nikkei.com実践Vim 思考のスピードで編集しよう！実践Vim　思考のスピードで編集しよう！ (アスキー書籍)作者:Ｄｒｅｗ Ｎｅｉｌ,新丈 径角川アスキー総合研究所AmazonVimのコア機能を使いこなす手法に特化した本書。Editorはソフトウェアと触れ合う時の私の手の延長です。もっと、プログラミングが上手くなりたい。だから、使っているVim の達人になりたいとも考えている。なので、読んでいる。Tips集なのでやっていけば勝手に強くなる。思考のスピードを超えないように注意が必要だとは思っています。自分が好きなEditorを利用すれば良いと思っている。syu-m-5151.hatenablog.com終わりに他にも面白かった技術書はたくさんあるが発表やブログにしたものから厳選しました。これを書きながら技術書を読んでよかったと思えるのは常に自分の能力がその書籍を装備できるまでレベルが上がってからだなって思いました。ちなみに、3-shake Advent Calendar 2022の予備で途中まで書いていたブログです。皆さんが勤勉なので書くことにはなりませんでしたが人生で振り返ることが大事なので振り返ってみました。

SREとして2022年読んでよかった技術書7選

これは SREのカレンダー | Advent Calendar 2022 - Qiita 9日目のエントリです。昨日はryosukes さんによる「北欧、暮らしの道具店」インフラ構成の変遷、5年間の課題と取り組み でした。はじめにこんにちは。株式会社スリーシェイク Sreake 事業部に所属している@nwiizo です。Sreake事業部は技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。事業部にはさまざまな背景を持つSREの専門家が多く在籍してます。しかし、そのSREの専門家達とは案件が一緒にならなかったり、能動的に質問をしなければSREに関する意見や知見を聞けませんでした。SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践オライリージャパンAmazonそんな、課題がある中で半年前に各案件で得た知見や経験を各メンバーで出し合える会がもっと(社内で技術共有会はあるため)あると良いと思いました。そこで社内チャットで運営を募り 『輪読会について考える会』を行いました。社内チャットで運営を募ると一瞬で集まったので良い組織だと思いました。※『輪読会について考える会』の議事録のTOPページです。『SREの探求』輪読会この輪読会を開催するにあたって以下の3つを目的として上げました。各メンバーがSREに関する意見や知見を交換できる場にするチーム全体としてSREへの理解を深めることでSreake の価値を高めるさまざまなフェーズの意見が交換できるように『SREの探求』を読む候補としてSRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームやサイトリライアビリティワークブック ―SREの実践方法 も上がりました。しかし、Google だけではなく様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践が紹介されているということで『SREの探求』に決定いたしました。輪読会の形式リモートで毎週水曜日 18:00から1時間、業務もあるので参加は自由としました。進め方としては担当者がNotion に担当の章をまとめて内容を発表する。その後、話し合いながらNotion やSlack に意見を垂れ流す方式にしました。参加者はSREの専門家達、リーダー、人事、営業、総務など様々な方がいてわいわいとやれているので僕は楽しい。輪読会をはじめてから半年が経過して開催できてない週もありましたが現在は14回の実施ができました。各担当者毎に特色がある発表で聞いていて面白いです。『SREの探求』には様々な視点でのSREでの話がされているので当初の目的としては正解です。また、同じ本で同じ職種なのにここまで読み方に差が出るのかと感心してます。人によってはすごくその事柄について考えられていて自分と比較して落ち込みます。でも、経験や考え方の違う人の話を聞けるのはとても参考と刺激になってます。『SREの探求』の輪読会のTOPページです。情報がシュッとまとまってます。また、1年が経過したタイミングで「輪読会に参加して、その後、SREに対しての考え方や行動に変化はありましたか？ 」という質問をしたいと考えております。もし、読んでる社内の方がいたら考えておいてください。さいごに『SREの探求』の輪読会を半年運営してきて各メンバーがSREやインフラ技術に関する意見や知見を交換できる場として機能し始めていると思ってます。自分自身もSREに関する知見を深める機会になっております。今後より良いサービスを提供していくためにも輪読会は続けていきたいなと思いました。輪読会をやる時には運営が複数人で実施することと目的を明確にしておけば運営を続けやすいなって思いました。『SREの探求』の輪読会を終了したタイミングでちゃんと効果測定したブログを書こうと【今は】思ってます。

SREの専門家が集まったチームで『SREの探求』の社内輪読会をやっているという話

OWASP Fukuoka Meeting #9 に登壇してきました！登壇してきました。自分はセキュリティ専門家ではないのですが発表するとセキュリティ専門家からレビューをもらえたり意見をいただけるのでそれがとてもよいです。ちなみに発表時間が諸事情により30分から1時間になって想定外の資料の取捨選択を行った...発表時間が30分から1時間になって想定してない肉付けしたら資料の主張が曲がったので改変している。— nwiizo (@nwiizo) 2022年12月6日  発表資料セキュア・バイ・デザインの鳴くところ - 安全なソフトウェアを全体から考えるみるで候の資料はこちらです『セキュア・バイ・デザインの鳴くところ』みたいな資料を作成したので公開しておきます！https://t.co/BduVhWd73K#owaspfukuoka— nwiizo (@nwiizo) 2022年12月7日  リモート発表は寂しいので相槌を入れてほしいと思っている。主催の@TakaharuOgasa さんや@mrtc0 さんが程よく補足情報を入れたりしてくれてよかった。セキュア・バイ・デザイン 安全なソフトウェア設計作者:Dan Bergh Johnsson,Daniel Deogun,Daniel Sawanoマイナビ出版Amazon参考資料OWASP SAMM(Software Assurance Maturity Model)OWASP SAMM(Software Assurance Maturity Model):githubOWT2017JP - OWASP SAMMセキュリティーチェックシートという闇への防衛術CircuitBreakerPattern: Circuit BreakerGitHub - istio/istio: Connect, secure, control, and observe services.Istio By Exampleサービスメッシュの「Istio」や、OSSで構成されたマネージドサービス――ミッションクリティカルなシステムをKubernetesで実現するカギはツールにあり！【デブサミ2018】Design It! ―プログラマーのためのアーキテクティング入門Release It!: Design and Deploy Production-Ready SoftwareOWASP SAMM Toolkit v2.0.6開発環境のセキュリティおよびCI/CDパイプラインのセキュア化PHPerKaigi 2022: 予防に勝る防御なし - 堅牢なコードを導く様々… / 和田卓人SOLID CODE 高品質なコードを生み出す実践的開発手法

『セキュア・バイ・デザインの鳴くところ』というタイトルでOWASP Fukuoka Meeting #9 に登壇しました。 #owaspfukuoka

このエントリーは 3-shake Advent Calendar 2022  2日目の記事です。前日は@koki_develop さんによるStep CI で手軽に API をテストする でした。Step CI は API をテストするためのシンプルなオープンソースのコマンドラインツールです。「第8章: セキュリティを意識したデリバリ・パイプライン」ではStep CI のようなツールを用いてデリバリ・パイプラインで正常値、境界値、異常値、極端値を検査することが推奨されています。qiita.comこのエントリーで言いたいことセキュア・バイ・デザイン という書籍の多様さセキュリティにおける設計の大切さ現代におけるセキュリティの幅広さと難しさが凝縮された一冊であるということセキュリティを面で捉える難しさと重要性このエントリーを書き始めた理由2022年12月7日20:00- よりOWASP Fukuoka Meeting #9で「セキュア・バイ・デザインの鳴くところ」というタイトルで登壇してきます。この発表ではセキュア・バイ・デザイン、シフトレフト、DevSecOps は何すればいいんだよ！ という人に対してOWASP SAMM version 2を軸にガバナンス・設計・実装・検証・運用でのロードマップを明確にして設計・実装に関してもいくつかのTipsに言及していこうと思います。このイベントはYouTubeなどで後から動画を公開しないので動いてる私が見たい場合には参加登録してほしいです。発表の動画は公開されないですが資料は公開する予定です。それに対する予稿的な意味合いで書き始めました。内容は違うのに...。目次このエントリーで言いたいことこのエントリーを書き始めた理由目次はじめに「セキュア・バイ・デザイン 安全なソフトウェア設計」の目次僕たち二番目の子豚良い設計と悪い設計の違いSREは8章から10章が必読3部から読んでも良いと思ったさいごに参考はじめに「セキュア・バイ・デザイン 安全なソフトウェア設計」はOWASP TOP 10のような既知の脅威をリスト化して問題のある実装に対する解法を実装に組み込むためのTips を紹介する書籍ではありません。開発中にセキュリティについて意識する必要はないというような主張をする書籍でもありません。また、ドメイン駆動設計(Domain-Driven Design: DDD)を用いて、設計する書籍なのでDDDで開発しないから関係ないというわけではないです。システムの設計時にセキュリティだけを切り出して別問題として考えるのではなく、システム全体の関心事として扱い、設計時に考慮するというような書籍です。セキュア・バイ・デザイン: 安全なソフトウェア設計 Compass Booksシリーズ作者:Dan Bergh Johnsson,Daniel Deogun,Daniel Sawanoマイナビ出版Amazon「セキュア・バイ・デザイン 安全なソフトウェア設計」の目次セキュア・バイ・デザインについて実例と共に見ていく導入編。ソフトウェアの作成におけるセキュア・バイ・デザインの基盤を構築する設計の原則、考え、コンセプトについて学ぶ基礎編。レガシー・コードの改善、モノリシック・アーキテクチャでよく起こる問題、マイクロサービス・アーキテクチャについて学ぶ応用編の3部構成になっています。第1部: 導入編第1章: なぜ、設計がセキュリティにおいて重要なのか？第2章: ちょっと休憩: 『ハムレット』の悲劇第2部: 基礎編第3章: ドメイン駆動設計の中核を成すコンセプト第4章: 安全性を確立する実装テクニック第5章: ドメイン・プリミティブ（domain primitive）第6章: 状態の完全性（integrity）の保証第7章: 状態の複雑さの軽減第8章: セキュリティを意識したデリバリ・パイプライン第9章: 安全性を考えた処理失敗時の対策第10章: クラウド的考え方によるメリット第11章: ちょっと休憩: 保険料の支払いなしに成立してしまった保険契約第3部: 応用編第12章: レガシー・コードへの適用第13章: マイクロサービスでの指針第14章: 最後に：セキュリティを忘れるべからず！僕たち二番目の子豚家を作る時には壊れにくく、泥棒に盗まれにくい家を考えるのは当たり前です。家のセキュリティにコストをかける必要性は有名なの子豚が教えてくれたとおもいます。開発者はビジネス・ロジックを実装に落とし込みながらセキュリティの脆弱性についても考えなくてはならない。しかし、実装の優先するあまり一番目の子豚のような実装を行ってしまいます。そんな人たちを笑う二番目の子豚もいます。実装を行う開発者は常にセキュリティに関するスペシャリストというわけではないです。それを求めることも現実的ではありません。そのため、WAFを入れたり、脆弱性診断を行ったりします。しかし、それらも絶対ではありません。特に二章の"ちょっと休憩: 『ハムレット』の悲劇"で紹介された。ECサイトで「-1個」購入できるようになってしまうようなインシデントに関する話に関してはWAFがちゃんと設定されてないと無力だったりもする。ちなみに全体を通してセキュリティを意識しないことが大事だというが最終章の14章では全く逆のセキュリティを意識する重要性について説明されている。良い設計と悪い設計の違い全員にレベルの高いセキュアコーディングを要求するのではなく設計に意識を向けることで、従来のアプローチで抱えていたいくつかの問題に関して解決することを目的にしております。特に3-7章に関してはドメイン駆動設計を行う時にこれを意識しない場合にはこういうような脆弱性に繋がるという例は豊富でかつ示唆に富んでいる。また、本書はドメイン駆動設計から言葉、概念を拝借してはいるが"正しい使い方を簡単に、誤った使い方を困難に"ということを設計で達成しようぜと終始言ってるだけな気もする。あくまで私の感想ですけど。SREは8章から10章が必読SREという単語を利用したがこの文章も例に洩れずポジショニングトーク的にSREという単語を利用しておりますので何も言わないでください。SREコンサルという仕事をしているとSREの意味的なゲシュタルト崩壊を起こしてしまいます。情報セキュリティの３大要素にも入るぐらいなのでセキュリティにおいて可用性は重要です。8章から10章は特に私のようにSRE的な仕事をしている人間からするとアイデアの宝庫です。特に大事だと思ったのは使用しているツールのデフォルトの振る舞いを知ることの重要性についてです。既存のシステムで利用している秘伝のタレを継ぎ足しているだけで詳しくなったような気持ちになる。危険。本当はもっと、フォーカスしたいのでここは別でブログ書きたい。ちなみにOWASP Fukuoka Meeting #9のイベントではこの辺が話の中心に添えられている。3部から読んでも良いと思った防御的プログラミングのように良識あるようなTipsの積み重ねで問題発生を事前に防ごうというコーディングスタイルがあります。3部はわりとそれに近い内容に関する言及でレガシーコードとマイクロサービスでの注意点や改善方法がまとめられている。レガシーコードに関しては私の大好きなリファクタリング(第2版): 既存のコードを安全に改善するという書籍がある。もう、1章を追加するならセキュリティの概念を足したようなこの章が追加されてほしいと思いました。マイクロサービスの章に関しては現在、私がソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析という書籍を読んでいる。セキュリティ的な品質をソフトウェアの設計へ落とし込むには設計段階で考慮が必要。特に非機能的なので熟考に次ぐ次ぐだけ絶対にどうにかならず経験が必要な領域。最終章は具体的なコードレビューやアーキテクチャレビューにセキュリティの専門家が必要な重要性、脆弱性診断やインシデントハンドリングなどのセキュリティをがっつり意識した内容です。全てをひっくり返す感じがしてとても気持ちが良い。セキュリティの専門家はこの章まで耐えて「気持ちぃいいいいい(実際にどうなるかは知らない)」を経験してほしいです。さいごにあまねく全ての開発者に対してセキュリティの専門家と同等の知識が求められセキュリティに関する知識を常にアップデートしなければならないというこの時代。結局、安全な設計にもセキュリティにもお金が必要になる。地獄の沙汰も金次第。ちゃんと、コストを支払える会社に入社を果たし三番目の豚として幸せな生活をおくれるように祈ってます。本書は本当に良い本なのでこのエントリーで気になった人はぜひ、「セキュア・バイ・デザイン 安全なソフトウェア設計」を購入して熟読して実践してほしいです。明日は我らが長ATSによる「SRE事業をしているので「信頼性」について考えたくなった」です。参考OWASP SAMM version 2セキュア・バイ・デザイン 安全なソフトウェア設計プログラマが知るべき97のこと コードは設計である予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント良い設計と悪い設計の違い

「セキュア・バイ・デザイン」を読んで自分が何番目の豚かを考える。

「Dapr の概念と実装から学ぶ Observability への招待」 というタイトルで登壇します。https://event.cloudnativedays.jp/o11y2022/talks/1382:embed:cite セッション概要Dapr は CloudNative な技術を背景に持つ分散アプリケーションランタイムです。本セッションでは Dapr の Observability に関する各種機能と、その実装について解説していきます。さらにスリーシェイクの Dapr と Observability への取り組みに関してもご紹介します。Dapr の機能でカバーできる点...

nwiizo

Open InterpreterのDockerfile を書いたのでTipsとか

まずPR-AgentをPromptとします。

ChatGPT: SREがCustom instructions機能を利用する

SREからPlatform Engineerへの拡大というタイトルで登壇しました

2023年8月10日現在でLunarVim と Copilot.lua でのマルチラインサポートの改善方法

K8sGPT Deep Dive というタイトルで登壇しました #CNDF

CLIの実行結果を正しく理解することを促すツールを作成しました。

成熟度モデルを活用したCloud Nativeへの道筋という副題で登壇します #開発生産性con_findy

SREの専門家が集まったチームで『SREの探求』の社内輪読会を完遂しました。

Terraform Modules で再利用できるので最高ではないでしょうか？

はてなブログのコードブロックを”クリップボードにコピーする方法”について

Golang のEcho でMiddlewareを使ってPrometheus Exporter を実装する

Golang のEcho で Prometheus Exporter を実装する

ChatGPT:SREやDevOpsなどのソフトウェアの運用に伴う課題解決に関する提案を行うプロンプト

PHPカンファレンス福岡2023に｢State of DevOps 2022を読みながら、組織に適したSREの実践方法を探求する｣というproposalを出しました #phpconfuk

愛ゆえにお前はVimを使わねばらなぬ

Shell ScriptをGo言語に書き直す際に役立つ50本ノックなるものを作り始めた。

ChatGPTで障害対応 RPG v0.0.1を遊ぶには？

Terraform でDocker Provider を使いましょう

良いドキュメントを書きたくなる本を読んだらドキュメンタリアンになりたくなった

『2023年もSRE再考と叫びなさい!!』というタイトルで登壇しました

『自由研究には向かないウェブオペレーション』というタイトルで登壇しました。

Helm Chart の歩き方導入前に読みたいドキュメントについて

『ポストモーテムはじめました』というタイトルで登壇しました。

yaml 管理を自動化する時の必須道具 yq(v4) の倒し方

イェーイあけまして 2023

SREとして2022年読んでよかった技術書7選

SREの専門家が集まったチームで『SREの探求』の社内輪読会をやっているという話

『セキュア・バイ・デザインの鳴くところ』というタイトルでOWASP Fukuoka Meeting #9 に登壇しました。 #owaspfukuoka

「セキュア・バイ・デザイン」を読んで自分が何番目の豚かを考える。

Observability Conference 2022 に登壇しました

Open InterpreterのDockerfile を書いたのでTipsとか

まずPR-AgentをPromptとします。

ChatGPT: SREがCustom instructions機能を利用する

SREからPlatform Engineerへの拡大 というタイトルで登壇しました

2023年8月10日現在 でLunarVim と Copilot.lua でのマルチラインサポートの改善方法

K8sGPT Deep Dive というタイトルで登壇しました #CNDF

CLIの実行結果を正しく理解することを促すツールを作成しました。

成熟度モデルを活用したCloud Nativeへの道筋 という副題で登壇します #開発生産性con_findy

SREの専門家が集まったチームで『SREの探求』の社内輪読会を完遂しました。

Terraform Modules で再利用できるので最高ではないでしょうか？

はてなブログのコードブロックを”クリップボードにコピーする方法”について

Golang のEcho でMiddlewareを使ってPrometheus Exporter を実装する

Golang のEcho で Prometheus Exporter を実装する

ChatGPT:SREやDevOpsなどのソフトウェアの運用に伴う課題解決に関する提案を行うプロンプト

PHPカンファレンス福岡2023に｢State of DevOps 2022を読みながら、組織に適したSREの実践方法を探求する｣というproposalを出しました #phpconfuk

愛ゆえにお前はVimを使わねばらなぬ

Shell ScriptをGo言語に書き直す際に役立つ50本ノックなるものを作り始めた。

ChatGPTで障害対応 RPG v0.0.1を遊ぶには？

Terraform でDocker Provider を使いましょう

良いドキュメントを書きたくなる本を読んだらドキュメンタリアンになりたくなった

『2023年もSRE再考と叫びなさい!!』というタイトルで登壇しました

『自由研究には向かないウェブオペレーション』というタイトルで登壇しました。

Helm Chart の歩き方 導入前に読みたいドキュメントについて

『ポストモーテムはじめました』というタイトルで登壇しました。

yaml 管理を自動化する時の必須道具 yq(v4) の倒し方

イェーイ あけまして 2023

SREとして2022年読んでよかった技術書7選

SREの専門家が集まったチームで『SREの探求』の社内輪読会をやっているという話

『セキュア・バイ・デザインの鳴くところ』というタイトルでOWASP Fukuoka Meeting #9 に登壇しました。 #owaspfukuoka

「セキュア・バイ・デザイン」を読んで自分が何番目の豚かを考える。

Observability Conference 2022 に登壇しました

SREからPlatform Engineerへの拡大というタイトルで登壇しました

2023年8月10日現在でLunarVim と Copilot.lua でのマルチラインサポートの改善方法

成熟度モデルを活用したCloud Nativeへの道筋という副題で登壇します #開発生産性con_findy

Helm Chart の歩き方導入前に読みたいドキュメントについて

イェーイあけまして 2023