本日 #ssmjp 二本目、「運用改善、不都合な真実」の資料を公開しました。https://t.co/FLatAMO3Gz
— HATANO Hirokazu (@tcsh) July 22, 2024
ありがとうございました!
めっちゃ良い。特にこの問題認識は、運用改善に限らない。
— kokukuma (@kokukuma) July 26, 2024
> 単独の「課題」それぞれに対してピンポイントで対応していた。課題の数に比例して工数を消費する上、ツギハギの課題解決だらけになる
> https://t.co/gJpghb0ny1… https://t.co/7SrnqStjvP
まさにおっしゃる通り。
— HATANO Hirokazu (@tcsh) July 26, 2024
一方で、「特殊に見える要望」に新たな需要の萌芽を見出すこともあるので、きっちり要望を聞いて是々非々で対応することも大事。
かつそのような「特殊な要望」を標準サービスとして設計・提供できた時の達成感はめっちゃ大きい。 https://t.co/HoOVnZ6yUC
> 「特殊に見える要望」に新たな需要の萌芽を見出すこともあるので、きっちり要望を聞いて是々非々で対応することも大事
— kokukuma (@kokukuma) July 26, 2024
まさに! 要望の一つ一つって、自分たちの理想・実現したいことが、他のチームや会社・社会の要求とマッチしているかどうかをチェックするunitテストみたいなものなんですよね。
自分都合を押し付けてくるケースと、よく聞いてみると至極真っ当な要望であるケースがあるので、本当にしっかり聞いてみないと、もったいない&硬直的な組織に見られてしまうんですよね。
— HATANO Hirokazu (@tcsh) July 26, 2024
自分達の理想や実現したいことが社内や社会の要求とマッチしているか敏感であることは大事だなぁ、と思います。
いわゆるプライベートクラウド屋としては本当にこれ。
— てぃーじぇ (@tj8000rpm) July 26, 2024
「ユーザが困ってるんだから」という善意で個別要望を聞いてあげるだとスケーラビリティで崩壊する。いかにサービスとして特殊要望を汎化したソリューションに変えれるかを考えるのがこの仕事の醍醐味。
なお周りの理解は乏しい模様（ https://t.co/xjyleqKfJd
個別案件をやりたがる人ってUnix使ったことない人だと言う疑惑があって、既存の小さな道具の組み合わせで解決して欲しいことも、ほんの少しの違いですスクラッチから作るのを是としてしまうのよな。
— qooqle (@qooqle) July 26, 2024
いかにマルチックスが好きな人を諭せるか。。。コレが本当に重要なんよ。 https://t.co/LFb6HQ7wVm
ほんまそれです。
— てぃーじぇ (@tj8000rpm) July 26, 2024
zabbix一つとっても、zabbixの中に独自カスタマイズしたスクリプトいっぱい仕込みたいとか、監視のためにネットワークにいっぱい足生やしたい、AIだ、機械学習動かすんだみたいなの言うてる方々がいて、一つのことをうまくやるという発想はないのかとおもてしまいました
---そうやって思うと、小さな道具の組み合わせで何ができるのか、鬼のようにリファレンスドキュメントを用意するとなんとかなったりするのかな？
— qooqle (@qooqle) July 26, 2024
AWSとかCiscoが使いやすいのって、こう言うドキュメントの豊富さな気はしてるんだが、それを社内でやろうとすると顧客規模が小さすぎてスケールせんのがな。 https://t.co/u20FwNgrP1
個人的にAWSに入れ込んでいる理由として、「UNIXの考え方」を随所で感じさせられる(一つのことを上手にやる)ことと、豊富なドキュメントが提供されてことが挙げられます。
— HATANO Hirokazu (@tcsh) July 26, 2024
でも、読み込んでいくと全体構成がいけてないことにも気付くAWS公式ドキュメント… (手元で全体構成作り直して使ってますw https://t.co/fFoE5KaOrm
---ダメなリファレンスも含めてユーザーグループのネタになるんで、オープンなコミュニティ万歳ですねw
— qooqle (@qooqle) July 26, 2024
運用改善ではどうにもならなくて、再設計(非連続的な変更)をしたときの例。
— HATANO Hirokazu (@tcsh) July 26, 2024
その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 (JANOG42)https://t.co/Rfrh6ntVWM
運用改善、不都合な真実 / 20240722-ssmjp-kaizen https://t.co/slZyS5qbub
— Jun'' (@jungm__) July 26, 2024
>運用改善も自動化も効果は限定的
>やるべきは運用の再設計
わかりみしかなかったが言うが易しである
---これを言語化するのに15年掛かりました(笑
— HATANO Hirokazu (@tcsh) July 27, 2024
> 言うが易し https://t.co/sTfb4rraX5
この資料は、エンジニアが4桁いる会社で実際に自分がやってきたことをまとめたものです。
— HATANO Hirokazu (@tcsh) July 26, 2024
誰でもできる、とは言わないですが、この資料を見てやり方を変える人が増えれば良いと考えています。
(「正論だけど現実的ではない」と言ってしまった時点で実現しない、とは思っています。) https://t.co/vHPdOt2Mv0
いきなりグランドデザインを作ることは不可能、というのは、未経験ならその通りですが、ある程度業務経験がある人であれば、、、、できて欲しいなぁ。。。 (抽象化能力ある人が希少という問題)
— HATANO Hirokazu (@tcsh) July 26, 2024
言ってることは正論だとは思うけど、現実的ではない話かなあと思う。いきなりグランドデザインを作ることは不可能だし、「やればわかる！やらなければ、一生わからん！」という話があるので、知見が溜まったら定期的に全体を見直そうぜという方が妥当と思うけどねえhttps://t.co/H0N1Bo7lyU
— てるろー (@terurou) July 26, 2024
スモールスタート自体は悪くないと思うんですよ。「各部門からEXCELマクロが排除できないんですが！！！！」という感じで、ちょっと喉元を過ぎると全く見直しをかけずにそのまま残り続けることの方が問題
— てるろー (@terurou) July 26, 2024
「スモールスタート自体は悪くない」というのは経験を積ませるという意味ではおっしゃる通りですが、業務本番について言えばマネジメントやアーキテクトが機能していない、っていうことです。。。
— HATANO Hirokazu (@tcsh) July 26, 2024
「スモールスタートではじめよう」って言葉が出てくると「それはプロの仕事ですか?」と感じる派です https://t.co/GHQO3BwuJZ
現場の創意工夫の積み重ねでクソ運用が出来上がることをクソと言うこと自体はまあ間違ってないと思うんだけど、かといって、「現場で勝手な改善をするな、御上から沙汰が下るのを待て」というのも傲慢だとは思うんよねえ。
— てるろー (@terurou) July 27, 2024
「上がやるべきことやってないので、現場の工数が無駄になっている」と言いたいんですが、なかなか伝わらないものですね…
— HATANO Hirokazu (@tcsh) July 27, 2024
あと、現場も良かれと思ってやっていても、悪化の片棒担いでいることに気付かないとダメだよ、と言う観点はあります。(それを傲慢と言われるのですかね… https://t.co/dl1idmHejt
---プロフェッショナルとして、「自分の工数が無駄になるけど良いですか?」とマネジメントに問う&説明することは、大事な責務の一つだと思うんですが、そうでもない、ですかね?
— HATANO Hirokazu (@tcsh) July 27, 2024
(自分も上手く説明できた時と出来なかった時が当然ありますが > アウトプットの質に直結)
スモールスタートって全体の計画を作った上で部分から始める場合、そもそもインクリメンタルにやっていく場合、草の根的にやっていこうという場合が混在している気がする。どれが正しいということもないが、文脈を意識しないとかくあるべしな人と衝突が起こるから認識合わせは必要よなという感。 https://t.co/FDPayuQYyf
— 天野遠景@がんばれない (@tokagetail) July 27, 2024
マネジメントやアーキテクトがきちんと機能している組織で、チャレンジングな領域について、リスクと組織知の蓄積を勘案した上で、本番環境でスモールスタートする、ならばコントロール可能なのでありですが、そんな組織がどれくらいあるのか...
— HATANO Hirokazu (@tcsh) July 26, 2024
自動化でも、IaCでも、運用改善でも「スモールスタートではじめよう」という発表が多すぎる問題。
— HATANO Hirokazu (@tcsh) July 26, 2024
そういうのは、個人の趣味や研鑽でやるべきで、お仕事でやるときは「勝ち目が見えてから」やるべき。
そのためにPoCや検証は必要ですが、本番でやっちゃだめ。
(問題が露見する頃には自分は担当から外れられてるはずだろうから)スモールスタートではじめましょう、という闇のパターン
— HAL_FS_H (@HAL_FS_H) July 27, 2024
時間稼ぎパターンｗ
— 天野遠景@がんばれない (@tokagetail) July 27, 2024
大きめの企業だと割と見かけるパターン。
— HATANO Hirokazu (@tcsh) July 27, 2024
しばらく前だとkubernetes関連とか、最近はIaCが圧倒的にこれ… https://t.co/ex8bkOSvd3
研鑽を大きめの企業で業務としてやるのがITだと許されないとするとマジ闇ですな。研究所なんて研鑽しか無いのに。
— ARAKI Yasuhiro ☁ AWS Solution Architect (@ar1) July 27, 2024
本番導入ありきでやるのがあかんのですよ… (ポイントオブノーリターンからの片道切符
— HATANO Hirokazu (@tcsh) July 27, 2024
阻止限界点探しが必要になりそう
— ARAKI Yasuhiro ☁ AWS Solution Architect (@ar1) July 27, 2024
0 件のコメント:
コメントを投稿