タグ

運用と考察に関するlocke-009のブックマーク (7)

  • AWSが教えてくれないコスト削減の小話いろいろ | 外道父の匠

    米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ

    AWSが教えてくれないコスト削減の小話いろいろ | 外道父の匠
  • そりゃスパゲティーコードにもなるよな - orangeitems’s diary

    お気の毒に・・。 www.nikkei.com スパゲティコードになるプロセスはよーくわかる。 仕様変更に次ぐ仕様変更、当初の想定が間違っていたことのフォローアップ、一つ一つ丁寧に進めていきつつ、当初の見積工数を超えないようにこれまでの成果物をできるだけ活かしたら、最終的にできるのはスパゲティーになる。 スパゲティーを作る人が悪いんじゃなくて、オーダーした人がスパゲティーを望んだからだとしか言いようがない。スパゲティーを作って欲しいと言っている人に、スパゲティー以外を料理する方法が思いつかない。麺類なら許されるのか?。 大企業のプロジェクト運用体制に、1つ起因する問題もある。長期に運用するシステムの場合、同じ担当者がずっと担当し続けることが難しいことだ。人が入れ替わる前提だと、毎回引き継ぎのタイミングで過去の情報を振り返らないといけない。この時ほぼ情報は抜け漏れる。どんなに優秀な人が担当し

    そりゃスパゲティーコードにもなるよな - orangeitems’s diary
  • クラウド時代も「アプリ」と「基盤」のチーム分けで本当にいいの? - Qiita

    私は新卒のときから10年ほどIT業界、ときには会社を移りながらエンタープライズのSI(System Integration)のさまざまな現場で働いてきましたが、システム開発のチーム編成として「アプリケーション担当」と「インフラ担当」に分かれていることが長らく当たり前でした。 最近はAWSをはじめとするパブリッククラウドの台頭、特に抽象度の高いマネージドサービスの普及によって従来型の分業モデルが理に叶わなくなってきたのでは?と感じることが増えたので、ポエムを書いてみます。 みなさんの案件はどんなチーム分けですか? 私がよくいた「エンタープライズの業務システム開発」はこんなフォーメーションが多かったです。 とある社内向けWebシステムの開発体制 ユーザー企業(発注元の会社スタッフ) アプリケーション担当:通称「業務」。要求定義と仕様調整。事業会社だとコードレビューまではしないところが多い印象

    クラウド時代も「アプリ」と「基盤」のチーム分けで本当にいいの? - Qiita
  • 僕が考えた最強の作業手順書 - Qiita

    某所で見かけたシステム運用作業手順書の記事に、「作業直前に作業手順書の変更はしない」「手順書に無い作業をしない」といった事が書かれていました。 いや、それはあくまで心掛けの話であって、それも大事だけど、そもそも作業手順書はどうあるべきかという話が抜けおちているのではないか?それは世間ではあまり明文化されていないのではないか?と思いました。 不遜ながら、私が思う作業手順書のあり方を書いてみます。 1. 存在している まさか、番作業を勘とノリでやっちゃうなんて。まさかね… 2. 保存されている Githubでも、Google Driveでも、Notionでも、Wikiでもいいですが、作業手順書は保管されていますね?えっ?保存していなかったら、同じような作業をもう1回することになったらどうなるんですか?障害が起きて、デプロイ手順に問題がないか調査したい時にどうするんですか? なお、保存するなら

    僕が考えた最強の作業手順書 - Qiita
  • リファクタリングの価値の考察 - プログラマーの脳みそ

    リファクタリングには価値がある、とプログラマは確信していることだろう。しかし、その価値が何であるか?を上手く説明できるかというと難しいのではないだろうか。稿ではリファクタリングの価値をテーマに筆者の説を提示していく。 品質特性の側面から 補足 品質特性の相互作用 リファクタリングの価値 障害対応 機能追加 システムの製品寿命 まとめ 品質特性の側面から ソフトウェアの品質特性としてISO/IEC 9126が一般的に用いられている。大きく6つの特性と細分化された副特性からなり、ISO/IEC 9126 - Wikipedia から引用すると 機能性(functionality) - 機能とその特性に影響する特性群 信頼性(reliability) - ある状況がある時間続いたときにソフトウェアがどの程度機能するかに影響する特性群 使用性(usability) - 利用するのにかかる手間、個

    リファクタリングの価値の考察 - プログラマーの脳みそ
  • なるべく楽したいAWSセキュリティ

    AWSのベストプラクティスに従う SecurityHub でセキュリティチェック なるべく持ち物を減らし、ツールの既定に合わせる Fargateを使い管理対象インスタンスを減らす ネットワーク環境構築をCopilot CLIに任せる アプリケーションレベルでもAWSサービスを活用する 典型的な攻撃はアプリ到達前にWAFで防ぐ ECRコンテナスキャンで脆弱性をチェックする

    なるべく楽したいAWSセキュリティ
  • データ基盤をサーバーレスで構築したので概要を紹介 - Adwaysエンジニアブログ

    あけましておめでとうございます。年もよろしくお願いいたします。 久しぶりに登場しました菊池です。 僕は昨年から新しいデータ基盤を構築するプロジェクトを担当しておりまして、最近システムが無事に実稼働してホッと一息したところです。思い起こせば入社時はインフラ担当部署に配属だったのが、広告配信システムの開発をやったり、カジュアルゲーム作ったり。新規事業のスマホアプリを作りつつサーバーサイドの API を作って立ち上げたり、海外向けのサービスを作ったり。いつのまにかメディア運営に関わったりしてきましたが、最近はデータ基盤の開発もやってます。そんなキャリアを歩んできましたが、いつか森の中の開けた草原にあるネット環境の整ったポツンと一軒家で、庭にチャボを放飼にしつつ養蜂をやってみたいと思っています。 話は戻りますが、今回はこの稼働したてホカホカ状態のデータ基盤について概要を紹介したいと思います。よろ

    データ基盤をサーバーレスで構築したので概要を紹介 - Adwaysエンジニアブログ
  • 1