日常の失敗も品質管理で解決できる - 本しゃぶり
失敗を後悔する「恥」としてはならない。 学習する機会と捉え、次に活かせばいいのだ。 そのためのスキルが品質管理だ。 失敗から学んでダブルチェックだと ちょっと前にこのツイートが流れてきた。 失敗を成功に変える唯一の方法https://t.co/0rF2myVk5I pic.twitter.com/9o88CNqSgj— ゆうきゆう/マンガ心療内科/セクシー心理学 (@sinrinet) June 27, 2021 基本的な主張は賛成だ。失敗から学ぶのはコスパが良い。複雑で全てを理解することができない世界において、対処すべき問題を明確にしてくれるからだ。失敗には特定のパターンがあり、対策しなければ未来にも同じ失敗が発生する。だから失敗から学び対策することは、未来の成功を助けてくれる。そして最も学習効率が高いタイミングとは、記憶が新しい失敗した直後だ。 また、失敗を精神論で終わらせないのも正し
プロジェクトの残業を50%削減したタスク管理手法を惜しみなく公開する - Qiita
おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括（開発は外部委託） サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク（チケット）運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行の徹底 進捗状況の逐次反映 そして、運用ルールの入念な教育（五十六メソッドを採用した） 当時はITSベースのタスク管理自体が社内で先進的な試みだったので、当時部下だった私もPMと協力して「できるだけ丁寧な運用」を心がけた。心がけた、のだが… おかしいな だれ
毎週のように依存パッケージを上げ続ける努力 - CARTA TECH BLOG
皆さんこんにちは。fluctにてfluct SSPという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。 依存パッケージの更新、どうしてますか？ 今や数多くの言語でパッケージマネージャが提供されており、みなさんも日常的にコミュニティによるパッケージエコシステムを活用していることと思います。 ですが、この依存パッケージの更新については、どのようにしていますか？ セキュリティfixなどを除き、以下のようなことになっていることが多いのではないでしょうか？ チームの「いい人」が頑張って更新し続ける その人の謎の情熱が消えると更新されなくなってしまう たまに気がついたら頑張る 「いい人」が頑張るタイプの亜種 気が付かなかったら更新されない 更新はリスクなので塩漬けにする プロダクトは定期的に作り直す前提 CIでテストを回し続けているのに更新しないなんて……とモヤ
MySQL バイナリログの削除 - とみぞーノート
1. 概要 MySQLでレプリケーションを行っているとMasterにバイナリログが溜っていきディスクを圧迫するので定期的に削除してやる必要がある。 2. 手順 2.1 レプリケーション状態の確認 まず、どこまでバイナリログを削除してよいかを調べる。 Slave側でSHOW SLAVE STATUSを実行し、Slaveがバイナリログをどこまで読み取っているかを調べる。「Master_Log_File」が現在参照中のバイナリログ。以下の例ではskylancer00-bin.000084を使用していることになるので、skylancer00-bin.000083まで削除してしまってよいことになる。Slaveが複数いる場合は、全Slaveについて確認を行う。 mysql> SHOW SLAVE STATUS \G *************************** 1. row ********
スケールアウト再考
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Shin Ohno
なぜネットワーク運用自動化が進まないのか Why is it difficult �to automate network operation
2015/4/24に開催された wakamonog x ssmjp x BIGLOBE = wasabi イベントで発表した資料です。http://ssmjp.connpass.com/event/13173/ This is lightning talk presentation for study event in Tokyo.
橋本商会 » Mobage運用技術勉強会に行ってきた
Web公開制限が無いらしいので、殴り書いたメモを貼り付けておく。 謎のアルゴリズムで集められたはてなユーザーに、モバゲーの運用技術を惜しげもなく教える勉強会に行ってきた。 インフラもPerlも全然わかんないんだけど何故誘われたのか謎。 モバゲーすごい・・・台風激しかったけど行ってきて良かった。特にモニタリング手法が面白くて、一瞬だけ全プロセスにデバッガをアタッチして待機状態のプロセス数を調べるとか、DBバックアップサーバーの遅延を監視してるとSlaveへの遅延発生が予測できるとか。頭いい。 たぶんMobageを支える技術に書いてある内容の一部だと思われるので、本も買ってみる。 あと社食で閉店前に「モバゲ〜」って歌が流れててわかめ高校みたいで面白かった。 2012年6月19日 @ DeNA 渋谷ヒカリエの21階 台風きてるからヤバかったらすぐ帰りましょう インフラ部門紹介（小野氏） 世界展開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
企業のためのオープンソース ガイド – The Linux Foundation
MySQLを割と一人で300台管理する技術
運用に自動化を求めるのは間違っているだろうか
https://atnd.org/events/66230
Javaトラブルに備えよう #jjug_ccc #ccc_h2
クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側（前編）。JAWS DAYS 2014