ふり返る暇なんて無いね

日々のメモ書きをつらつらと。メインブログに書くほどでもないことを流してます

故障と障害の違いがわからずに困惑してた

ふと調査ごとをしてて故障と障害ってなんか違いあるんだっけ?と疑問に思い調べてました。

JIS X 0014:1999 情報処理用語-信頼性、保守性及び可用性

いったん、JIS X 0014:1999の定義を見てみることにします。

故障は要求された機能の能力がなくなること。できごとを表す感じですかね?

故障
要求された機能を遂行する,機能単位の能力がなくなること。
備考 この定義はJIS Z 8115 : 1981と同一であるが,JIS Z 8115 : 1981には更に幾つかの備考がある。

なるほど。障害は要求された機能が実行できない異常状態らしいです。

障害
要求された機能を遂行する機能単位の能力の,縮退又は喪失を引き起こす,異常な状態。
備考 JIS Z 8115 : 1981では,予防保守又は他の計画的な作業の間に発生する場合,及び外部資源の不足のために発生する場合を除いて,要求された機能を遂行できない状態を“フォールト”と定義している

ちょっとこれだけだとよくわからないので、言及されてるJIS Z 8115を見てみましょう。

JIS Z 8115 : 2000 デイペンダビリティ(信頼性)用語

JIS Z 8115 : 1981が見つからないので今回はJIS Z 8115 : 2000を見ていきます。

これも機能を失うこと。イベントですね。故障はイベント、フォールト(障害)は状態という区別らしいです。そしてそれらを厳密に区別しないこともある。

故障
アイテムが要求機能達成能力を失うこと。

備考1.  一般に,アイテムは故障の後フォールトをもつ。
2.故障は,イベントであり,状態であるフォールトと区別される。
3.ソフトウェアを含むシステムは故障事象をもち,その要因はシステムを構成するハードウェア,ソフトウェア,及び人的要素等の個々の状態又はそれらの組み合わさった複合状態に起因した不具合及び故障によっても発生する。
4.システム故障は系全体の機能の喪失又は規定された機能水準を下回る,系の一時的機能低下,すなわち,系のサービス中断として用いる。
5.ソフトウェア故障という用語は,一般にシステム故障が発生したときの状態において使用される。
6.イベントと状態を厳密に区別しないで故障ということかある。参考  正しい理解と使用のために解説を参照する

障害にあたるフォールトを見てみると。1つ目は機能が実行できない状態。2つ目がちょっとわかりにくいですが、こちらも状態としてとっていいのかな。

フォールト
a)ある要求された機能を遂行不可能なアイテムの状態,また,その状態にあるアイテムの部分。
b)アイテムの要求機能遂行能力を失わせたり,要求機能遂行能力に支障を起こさせる原因(設計の状態)。ただし,予防保全又はその他の計画された活動にる場合,若しくは外部からの供給不良による場合は除く。

備考1.  フォールトはアイテム自体の故障の結果であるが,先行ずる故障がなくても存在することがある。
2.故障発生の過程を原因−結果の連鎖とした場合,故障の原因をフォールトとみなすこともある。フォールトは,着目しているアイテムの下位のアイテムの故障である場合もあるが,アイテム自身に内包されている場合もある。
3.ソフトウェアアイテムの場合,コンピュータシステムではプログラム全体てのプログラミング,論理構成,プログラムプロセス,チータ定義などの間違いを意味する。
4.ソフトウェアフォールトはハードウェアの故障要因と区別するときに使用する場合がある。参考  正しい理解と使用のために解説を参照する

ところで、アイテムとは、

アイテム
ディペンダビリティの対象となる,部品,構成品,デバイス,装置,機能ユニット,機器,サブシステム,システムなどの総称又はいずれか。
備考1.  アイテムは,ハードウェア,ソフトウェア,又は両方から構成される。さらに,特別な場合は,人間も含む。
2.複数のアイテム,例えば,アイテムの母集団及びサンプルは,それ自身アイテムとして考えることができる。
3.ソフトウェアアイテムとして用いる場合は,例えば,ソースコード,オブジェクトコード,ジョブ制御言語.関連文書類又はこれらの集合体を指す(SW1 参照)。
参考  IEC 60050 (191)  の対応英語 entity は除いてある(解説を参照)。

ISTQB 用語集

昔、JATQBの試験を受けたときにこの辺の単語見た気がしたので改めて用語集を見てみます。

ISTQB Glossary failure

日本語だと状態を表してるように読み取れますが、原文だとEventになってます。JISでいうところの故障と同じような概念を指してるように見えます。

故障(failure)
コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと。
An event in which a component or system does not perform a required function within specified limits.

ISTQB Glossary fault

フォールトそのものは載ってないのですが、Synonymとしてdefectがありました。ただ、JISでいうところのフォールトとは違う意味のように取れます。うーむ?

欠陥(defect)
作業成果物に存在する、要件または仕様を満たさない不備または欠点。
Synonyms: バグ(bug), フォールト(fault), 問題(problem)
An imperfection or deficiency in a work product where it does not meet its requirements or specifications.

結果

余計困惑しました。

アイテムが故障した結果、フォールト(障害)の状態になるというのが基本的な理解で、ただ、故障とフォールトは厳密に区別せずに使われることもある。そういう理解で良いのでしょうか?

ワクチン4回目打った💉💉💉💉

3回目までは職域接種だったのでモデルナだったのですが、今回は転職して、職域接種なさそうなので、近くのクリニックでファイザーを受けてきました。

オミクロン対応の2価ワクチン(BA.1)ですね。

前回までは、副反応で頭痛と熱が出ててだいぶ辛かったのですが、今回はファイザーなせいか今の所寒気がする程度です。今回鎮痛剤をもらってないので不安だったのですが、この漢字なら耐えられそうです。

11月末ターゲットで2個資格試験受けます

Google Cloud Professional Cloud DeveloperとKubernetes and Cloud Native Associateを11月中に受ける予定です。

KCNAはたぶん大丈夫だと思いつつ、PCDの方は10/28から新しい試験に変わるんですよね。変わってみないと状況がちょっとわからないですが、PCAを受けてみたみた感じの難易度はそこまででもないので、難易度が大幅に変わらない限りは順当に勉強すれば行けそうな気はしてます。

ただ、11月からのお仕事はGoogle CloudもたぶんKubernetesも使わない気がしてるので、その点モチベーション上がりにくいですが、未来への自己投資ということで、がんばりまっする💪

技術書を複数回読むということ

これは技術書に限らずどの本にも当てはまるのかも知れないです。最近既読の技術書を読み返したときに感じた、複数回読むことの効果に関する気付きです。

次から次に出てくる新しい本や新しい技術に終われて持ってる本を一読するだけでもつらいのに複数回読む時間がなかなか取れないと思いますが、新しい本を読む時間を削ってでも理解を深めるには2周目が大事だと感じました。

1回目読むときにも得るものはあるのですが、自分自身理解力がある人間ではないので、2回目でやっと理解できることが多いなと感じてます。

また、ある程度技術要素を理解した後に読み直すと新しい発見だったり、今まで理解できてなかった概念をひもとけたりと良い効果があります。というか今現在下記の二つの本を読み直してて、特に感じてます。

もののジャンルや難易度にもよって変わるかも知れませんが、概念をつかむために一読、ある程度その分野を触ってから二読目をすると効果が高いんじゃないかなと感じました。

積ん読に焦らず、自分が身につけたい分野の本はじっくり腰を据えて複数回読むことが大事だなと感じた今日この頃でした。(目の前の大量の未読の本から目をそらしつつ)

まとまってないし、オチも特にないです。

GitHub Actionsで `save-state` と`set-output` が廃止されるようです。

ふとGitHub Actionsを実行ログを眺めてたら、下記のwarningsがでてることに気づきました。

The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

なんだろと思いつつ、示されてた参考リンクを見ると set-output が使えなくなる模様。

10月11日にリリースしたrunner version 2.298.2からこのwarningsがでるようになってて、2023年6月1日からsave-stateまたはset-outputを使うと失敗するようになるので、それ以降使えないとのこと。

それまでに対応する必要がありそう。

リンクの例に書かれてますが、今回使えなくなる set-outputsave-state の形式がこれで、

- name: Save state
  run: echo "::save-state name={name}::{value}"

- name: Set output
  run: echo "::set-output name={name}::{value}"

今後は、こっちのように指定のファイルに出力するように対応すれば良い。

- name: Save state
  run: echo "{name}={value}" >> $GITHUB_STATE

- name: Set output
  run: echo "{name}={value}" >> $GITHUB_OUTPUT

しかし、10月11日からwarningsでてたはずなのに気づいてなかった。。。

はてなブログのカテゴリごとのRSSフィード

こんな形式のURLになってます。

https://${domain}/rss/category/${category}
https://${domain}/feed/category/${category}

うちのでいうとこんな感じですね。

このブログわりかし技術系以外の内容が含まれてるので、技術系のカテゴリだけslackに流したいなと思って、特定カテゴリだけのRSSフィードがないか探してました。

これで良い感じにできそう。

未解決: Google Cloud Storageの静的配信でnginxで言うところのtry_files的なことをしたかった。。。。

結論から言うと、ページとしては想定のものが返ってきてるが、status code 404が返るようになってうまくいってないです。

nginxだと下記の様に設定すると、指定されたファイルを探して見つからなかったら/index.htmlを返す(それもなかったら404を返す)。ということをしてくれます。

try_files $uri /index.html =404;

シングルページアプリとかだと返して欲しいhtmlはindex.htmlだけど、パスに応じて挙動を変えるみたいなことをしてると思います。これに対応するために上記の設定をしています。

もともとNginxをCloudRunで動かして、これをやっていたのですが、どうせ静的配信しかしないならCloud Storageでいいのでは?となって移行しようとしています。

これと同等のことCloud Storageでやるには、NotFoundPage = index.htmlを指定するとよさそうです。terraformで書くとこんな感じになります。

resource "google_storage_bucket" "website" {
  name          = "${local.name}-site"
  location      = "ASIA1"
  storage_class = "MULTI_REGIONAL"

  website {
    main_page_suffix = "index.html"
    not_found_page   = "index.html"
  }

ページの表示としてはうまくいったのですが、status codeが404で返ってきてしまいます。これをうまく200で返す手段がCloud Storageとロードバランサの組み合わせでは見つかりませんでした。

CloudFunctionsでうまくごにょごにょすれば良いかもですが、だったらCloud RunでNginxをサーブする方がシンプルにできそうで良いのでは?と言う気持ちになってます。なにかシンプルなうまい方法ないですかね?

参考:

横須賀で温泉入ってきた

温泉に行きたくてふらっと横須賀温泉に行ってきました。海を見ながらの温泉は最高でした。

www.yurakirari.com

湯上がりに横須賀に似つかわしくないビール。

お湯を上がった後は馬堀海岸で海を見ながら散歩してました。良い眺め。そして、横須賀に似つかわしくない食事。

お昼はここで、地魚丼をいただきました。はい。

www.uogashi-hamakura.com

Google Cloudの外部HTTP(S)ロードバランサと外部HTTP(S)ロードバランサ(従来型)の違いがわからなかった。

外部HTTP(S)ロードバランサには無印と従来型の2つがあります。この辺まとめてるのが日本語では見つからなかったので、ざっくりとドキュメントからかいつまんでみました。

従来型を使いたい特別な理由がない限りは無印を使うとよいのかなとます

無印 従来型
特徴(作成時のツールチップより引用) 複数のリージョンにグローバルに分散されたユーザーまたはバックエンド サービスを持つ外部 HTTP(S) ワークロード向けに推奨されるロードバランサです。このロードバランサは、従来の HTTP(S) ロードバランサよりも多くの機能がある、高度なトラフィック管理機能を備えているため、トラフィックの処理方法をきめ細かく制御できます 従来のグローバル HTTPS ロードバランサは、グローバル HTTPS ロードバランサの以前のバージョンであり、高度なトラフィック管理などの機能をサポートしていません
ネットワークティア プレミアムティア スタンダードティア、プレミアムティア
GKE互換 スタンドアロンNEG IngressまたはGateway
Cloud Armor bot管理を除く bot管理を含む
セッションアフィニティのオプション ヘッダーフィールドとHTTP Clookie未対応
ロードバランサースキーム EXTERNAL_MANAGED EXTERNAL
その他 Envoyプロキシを使用した高度なトラフィック管理

あとの細かいことはドキュメントを見てください。