2023年7月12日のブックマーク (8件)

  • DNS水責め攻撃と監視 / DNS water torture attack Monitoring and SLO

    mackerel Meetup #14 Tokyo - 2023/07/11

    DNS水責め攻撃と監視 / DNS water torture attack Monitoring and SLO
    mom0tomo
    mom0tomo 2023/07/12
  • 曖昧なタスクへの耐性が下がってしまった、一時期の話

    この記事で書きたいことは、大筋以下のようなことです。 ・「曖昧さ耐性」についての記事を読みました ・部下の曖昧さ耐性の有無と状況に合わせて指示の出し方をコントロールする必要がある、というのはその通りだと思います ・ところで私には、自分の「曖昧さ耐性」を顕著に下げてしまった経験があり、「部下の曖昧さ耐性を下げない為にはどうすればいいか」を常々考えています ・重要なのは、チーム内での「成果物のフェーズ」に関する意識の統一ではないかと思います ・成果物のフェーズ認識に不一致があると、作業者が無駄に疲弊するし曖昧耐性が毀損される場合があります ・「今は成果物の曖昧さを許容するフェーズ」という意識統一がとても大事です 以上です。よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 *** 先日、logmiBizさんでこんな記事を拝読しました。 曖

    曖昧なタスクへの耐性が下がってしまった、一時期の話
  • マイナーなSaaSのCIを作っているんだが俺はもうダメかもしれない - LIVESENSE ENGINEER BLOG

    はじめに CIの概要 出てきた課題と対策 ライブラリのtimeout値が固定値な上に短い ドキュメントにないパラメータがダマで増えた モニターのゾンビ化 想定したように設定が反映されずに手動で変更 YAMLのdiffツール(dyff)の自己主張が激しい 結局CI化するべきだったのか? 得られたメリット 正直な感想と今後 はじめに インフラGの@yjszkです。先日は青森競輪と盛岡競馬に行ってきて負けました、盛岡のジャンボ焼き鳥が美味しかったです。 さて、前回の記事ではCronitorというサービスのコード化と、CIの構築を行ったことを書きました。 それを実際に運用してみたところ、いくつかの問題が発生しました。今回は、それに対して、現在進行形で苦労している話を書きます。 CIの概要 前回の記事にあるように、CIを構築しました。 GitHub Actionsを使用し、PRにコミットが積まれると

    マイナーなSaaSのCIを作っているんだが俺はもうダメかもしれない - LIVESENSE ENGINEER BLOG
    mom0tomo
    mom0tomo 2023/07/12
    鈴木さんの苦労のおかげでかなり管理やりやすくなった(でも大変そう
  • テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー:多くのエンジニアに愛される理由とは

    テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー:多くのエンジニアに愛される理由とは 『【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]』は、初版の発行部数は22,000部、2021年8月出版の改訂版は13,000部に上り、技術書としては異例のシリーズ累計35,000部を突破しました。(2023年6月現在) ソフトウェアテスト専門企業であるバルテス株式会社の技術者が執筆した、ソフトウェア開発工程のテストについて、基礎からしっかり体系的に学習できる格入門書です。 このストーリーでは、初心者から上級者まで幅広い層に読まれている、ソフトウェアテストのバイブルともいえる書完成までの経緯や苦労話、著者であるバルテスの石原 一宏氏と布施 昌弘氏が伝え続けたい想いをお伝えします。 テスト設計に必要な考え方を身につけられ

    テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー:多くのエンジニアに愛される理由とは
  • 運用現場におけるSRE本の「正しい」読み方

    ssmjp 201712 はたのさん祭での「運用現場におけるSREの「正しい」読み方」発表資料です。 詳細: https://www.opslab.jp/publish/20171212-ssmjp-sre.html (運用設計ラボ合同会社 波田野裕一)

    運用現場におけるSRE本の「正しい」読み方
    mom0tomo
    mom0tomo 2023/07/12
    良い
  • https://www.japacom.co.jp/blog/toda/p5/1-25.shtml

    mom0tomo
    mom0tomo 2023/07/12
    “SREチームには『人間(人材)』『哲学とマインドセット』『エンジニアリングの実践とツール』という3つすべてが必要”
  • SRE本まとめ(1章 イントロダクション) - Qiita

    Dev(開発)とOps(運用)を分離することによるOps観点でのメリデメ メリット 業界的にナレッジが蓄積されており、学習&真似がしやすい。 人材確保しやすい。 デメリット マニュアルでの運用がベースとなるため、サービスの規模に比例してチームの規模が大きくなってしまう。 開発と運用でバックグラウンドが異なるために衝突しやすい。 開発はスピードを素早くリリースしたいという目標に対して、運用は極力問題が起こさないようにしたいという開発とは逆行する目標となってしまう。 上記デメリットに対するGoogleのアプローチ ソフトウェアエンジニアにサービスを運用させることで、自動化をすすめた。GoogleのSREの大半はソフトウェアエンジニアリング+一連の技術的スキル(主要なものとしてUNIXシステムの理解&ネットワーク(L1~L3))を持っている。さらに全てのSREに共通するのは、複雑な問題を解決する

    SRE本まとめ(1章 イントロダクション) - Qiita
    mom0tomo
    mom0tomo 2023/07/12
  • SRE として3年半働いてみて - ymyzk’s blog

    この記事は CAMPHOR- Advent Calendar 2021 23日目の記事です.22日目の記事は @sanposhiho の「Pod Topology Spread Constraintsのすべて」でした. この記事では,CAMPHOR- 卒業後に Site Reliability Engineer (サイト信頼性エンジニア・SRE) として働いてきた経験をもとに,SRE とはどういう仕事をしているのか,どのようなスキルを利用しているかなどを紹介します.これまで対外的に SRE について文章を書いたことはあまりなかったのですが,SRE の役割はまだまだ広く知られておらず「SRE って結局なに?」と思っている人も多くいるように感じるので,せっかくの機会を生かして自分の経験を書いてみようと思います. 対象読者 主に SRE について興味のある学生やジュニアなエンジニアの方を想定して

    SRE として3年半働いてみて - ymyzk’s blog
    mom0tomo
    mom0tomo 2023/07/12
    "ソフトスキル"