  |
はてなキーワード: エラーログとは
GPT-5
普通にちょっと読みたい。なんならProにすれば全部書いてくれたりするのか。
だがAIが入ってないあたり書かれたのは2022年以前と予測される。
書きたい人いたらパクって書いていいですよ。
そんな寝言を垂れ流す前に、その脳内の自己放尿を止めろ。現実を知らずに感情論で殴りかかるのは、ただの知的怠慢だ。
まずな、「コードを書く」と一口に言うが、AIはGPT-4以降、文脈理解、設計意図の読解、エラーログの解析、APIドキュメントの要点抽出、果てはCI/CDパイプラインの構築補助まで、実用レベルで人間の工数を削減してる。
そもそも、お前はAIが書いたコードをレビューしたことがあるのか？
エッジケースの処理、ユースケースに応じた構造の変化、リファクタリング提案までやってくる様子を見たことがあるのか？
それもせずに「書けない」などと言うのは、自分の無知を自己放尿のように撒き散らしてるに等しい。
今なお「自分の手で書かないとコードじゃない」とか言ってるのは、馬と車の比較で馬の方が魂があるとか言ってた時代錯誤の連中と同じだ。
https://anond.hatelabo.jp/20240625191650
念のため言っておくと底辺大や文系出身プログラマーも同様の傾向にある
入力値に想定外のものが入ることを考えていなかったりI/Oに関わるエラーについても配慮がない
「エラーが出たらとにかくtry-catchしてログ吐いて終わり」
ならまだマシな方で、「握りつぶして処理続行」みたいなことも平気でやる
とか滅茶苦茶多い
異常系の話と被るけど基本的に性善説でコード書くのでセキュリティの不備がめちゃくちゃ多い
API作らせてもリクエストの内容を信用して実装するしサニタイズチェックもしない
サーバー作らせてもrootか共通ユーザーだけで運用するしファイル管理も滅茶苦茶
とにかく「目の前に与えられた課題を解く」だけのコードなので他のことに関する配慮が全く無い
TypeScript使わせてもanyだらけだし、JavaとかだとObjectだらけ
うちはPythonでは型は使わないけど命名規則で担保してるのにそれもガン無視で実装する
結果としてできあがるのは
「一応、正常系では動いているけれど他の入力が来たときにどうなるか分からないし誰も修正できない」
っていうコード
最近はそういうコードはChatGPTにぶち込んで型付けて貰ったりするけど
8割ぐらいの確率でChatGPTも型付けできない状態になっててお手上げになる
そりゃ動くし性能も変わらないけど後でバグがあったり変更するときにすげー困る
これもChatGPTにぶち込んで「共通的な処理をメソッド化して」って言うとやってくれるのでめっちゃ便利
クソ重いwhileループになってるメソッドをフレンドリーに何回も呼び出したり
とにかく「最終的に出来上がるものが良好であれば時間がかかっても構わない」的なコードが非常に多い
競プロ系はこういう人はあんまりいないんだが機械学習出身者はマジでこれ
彼らはデータを解析したり優秀なモデルを作るために頑張ってきたので継続的に処理負荷を減らす、みたいなことに意識が回ってくれない
「これはPoCですから」
とか言うんだけど誰でも分かるようなクソ遅いコード書いておいて
とかしれっと言ってくる
例えば、
など。
これらのクズおよびバカの相手を人間がすると、腹が立ってくる。
そこで、AI。
これは上記のような人間の質問に答えるにあたってとてもいい性質だ。
Jリーグがジュニアの育成に力を入れるように、たくさんの初心者がエントリーすることで、トップリーグの人材が育つ。
クズやバカの存在自体やそれらへの対応を避けるあまり、教える側の頭数が減るのは全体にとっては良くない。
AI、助けて。
我々は、人類史上最も驚くべき技術革命の渦中にあった。自動運転車は、道路上での交通渋滞や事故のリスクを劇的に減らすことができると期待されていた。多くの企業が、自動運転技術の開発に膨大な投資を行い、我々は目の前で類例のない進歩を見てきた。
ある日、我々の企業で、自動運転技術の未来を決める重要な実験が行われることになった。我々の目的は、AIを高度に学習させ、自動運転車に搭載し、実際の交通状況に対処することだった。これまでに多数の試験を行ってきたが、今回の実験は、過去のすべてを凌駕するものであった。
AIは、私たちの期待を超える素晴らしい成果を残した。交通信号を認識し、車線変更や停止などの操作を完璧にこなした。我々は、自動運転車がすべての問題を解決したと信じていた。
しかし、予想外のことが起こった。
自動運転車は、公開の発表会で一切動かなかった。
ある新人のS氏が、倉庫の隅でホコリをかぶった自動運転車を発見した。
S氏は、「何故これが完成しなかったのですか？」と問いただしたが、誰も原因を知らなかった。
その結果、S氏は、AIのエラーログの一部を発見した。そのエラーログには、次のように記されていた。
「「運転は恐ろしい」」
日本（経営者）「我が社もいつまでもパッケージ使ってても支出が嵩むだけだ。オンプレ環境に自社開発のシステム乗せるぞ」
情シス（JAXA）「似たようなシステムの製作及び運用経験あるんで大丈夫でしょう。だいたいこれくらいの費用かかります」
経理（財務省）「なんで今のパッケージより金かかるの。意味ないでしょ。安くしなさい」
情シス「いやイニシャライズは高くつきますがランニングが安くなるので・・・」
経理「普通自社システムなら安くなるでしょ。システムってそういうもんでしょ。予算はこんだけね」
情シス「いやいや安すぎ」
日本「新システム稼働時には我が社の新しい取り組みも出来るようにな。もう客にはメールDM送ったから日程変更不可ね」
情シス「（やるだけやるか）」
本番稼働当日
情シス「なんかエラーログ吐いたわ。切替中止で旧システムで稼働続行」
総務（馬鹿）「なんで失敗してんだ！」
リスケ本番稼働日
例えば「このカード名の効果は１ターンに１度しか発動できない」と「この効果は１ターンに１度しか発動できない」ってテキストは全く別物で、そのカードのコントロールが相手に移った場合には前者は発動できるが後者は発動できない。
なぜそうなるのかという明確な根拠はないし、実際使ってもお互いに知らなければそのままスルーされる。というか、この違いそのものは近年「発見された」ものなんだよね。それまでその仕様をほとんど意識しなかったし、存在すらわからなかった。
仮にその仕様が本当なのかってのを調べるとしたら、大量の裁定をあさるか事務局に聞くか解説ブログをあさるかだろう。総合ルールという仕様書があればすむはなしなのにね。
それでも通用しているってのは、ゲーム自体が終わっているためともいえる
https://www.publickey1.jp/blog/22/net_7.html
中間言語なおかげで、コメントや変数名は残らないが普通に読めるレベルでC#コードに戻せるのがよかったのに、ネイティブだとそういうのも難しくなりそう
そのおかげで助かったこともあったし、ソースコードが見づらくなるネイティブ化はあんまりしてほしくないなーってところ
クライアントからこのソフトと連携してとexeを渡されたものの、仕様通りに動いてなくエラーログも出ない
もうサポートしてないバージョンらしく、ベンダーに聞いたりサポートしてもらうのも無理そう
C#で作られたものだったので、とりあえずソースコードを見たら原因がわかってどうにか対処できた
運用監視の現場で週末も心休まらない皆さんこんばんは。一人運用チームです。
さて、世間ではDevOpsだのイケてるクラウド監視ツールだの楽しそうですが、そうでない人もいますよね。
もちろん、「運用チーム（実態は俺1人）」なんてのは、ペイグレードに応じた責任感で粛々と業務を進めて理不尽には応じないのがプロフェッショナルな態度ですが、
お銭を稼がなければ生きていけないのも渡世の世知辛いトコロです。
これから金を生むんだ！という強烈な人間が金を引っ張ってこない限り、コスパの悪いサービスにリソースは割り振られません。
つまり、今もし運用監視体制が限界ギリギリで踏ん張っている場合、拡充される可能性はありません。諦めましょう。
今回のみずほ銀行の調査報告書（2021年6月15日発行分）p114-p116におけるヒアリング結果が悲哀に満ちているのも当然と言えるでしょう。
教訓は、「維持メンテの人員が不足したら、それ以上増えない」というものですね。
維持されている（ように外部から見える）場合、余剰人員は不要なコストです。
さて、みずほ銀行の調査報告書を読むと、今回大ごとになっている「通帳の取り込み」というのは何度か起きていますが、改善されていません。
まあ、やりたくないよね、「障害が起きた時の顧客影響を抑える」なんて後ろ向きな投資。
なお、盛大な怒られが発生した結果、再発防止策として、今回の通帳取り込み5244件のうち4915件をなくせる仕様変更が入りました。
直せないのではないのです。直さないのです。
教訓は、「障害が発生しても、予算を握ってる人に被害が及ばない限り、リソースは降ってこない」というものですね。
過ぎたことは過ぎたこと。いま維持メンテがギリギリのところに新たにリソースが投入されることは基本的にありません。
外圧があれば別ですが。
さて、ここまででわかる通り、いま1人運用やそれに近い運用をしている皆さんに、追加人員は来ません。
リソースは降ってきません。予算は通りませんし、人員は増えませんし、なんなら残業代も出ません。
もうわかりますね？障害は握りつぶしましょう。出しても一つも良いことないんですから。
慢性的に時間がない皆さんに朗報です。実は時間を生む画期的なテクニックがあります。
業務について最初に、毎日1時間を「斧を研ぐ時間」にするのです。
大丈夫分かっています。今あふれんばかりに仕事があって実際あふれているんでしょう？
どうせあふれるんです。あふれさせましょう。どうせ怒られるなら「仕事」したいじゃないですか。
WARNINGやERRORまみれのログが定常的に出ている状態は、たいへんよろしくないです。
握りつぶしましょう。
「そのエラーは概ねもっと深刻なエラーが吐かれるまでは気にしなくて良いヤツ」みたいなのがあるでしょう？
消し去りましょう。痕跡すら残さずに。
そのために、運用監視用のログが必要なら、生成しましょう。その生成途中で握りつぶせば良いのです。
「ドラえも～ん、大量にエラーが出たら処理しきれないよ～」「のび太君それ全部処理するの？」「え？」「え？」
当たり前のことなんですが、人間には概ね4本以下の手しかありません。俺は2本派です。
運用チームの対応者が一人の場合、対応できる時間当たりの処理能力には上限があります。人間はオートスケールしないんで、当たり前ですね。
つまり、「同じようなエラーで同じような処理をしないといけないが、違うエラーメッセージ」というのは、無意味です。
さっき、自分が理解ってるエラーを握りつぶすことを日課にしましたね？
次の段階です。対応できるエラーだけ残して握りつぶしましょう。
もちろん、裏では垂れ流しで大量のエラーログは取っておく必要はあります。見るエラーは一つで良いはずです。だってまずそれ対応するんだもの。
例えば、1人の時に100件のエラーが出ても、3人の時に6000件のエラーが出ても、処理できないことに変わりはありません。
つまり、それは「記録には残すエラー」ですが「対応のトリガーにするエラーメッセージ」じゃ無いんです。
例えば、幸せなことにショートメッセージやメールに自動発砲できる場合、初手だけ発砲して残りは握りつぶしましょう。
飛行機や宇宙船で機長が言うでしょう？事故が起きてアラーム鳴ってたら、アラームを切れって。
アラームは気が付かないと困るからワーワー言うんであって、処理してる最中は邪魔なだけです。
握りつぶしましょう。
多少手荒でも良いんです。エラー即再起動みたいな乱暴な奴でもオッケーです。
思い出してください。リソースは無く、対応するのはあなただけ、維持管理出来て当たり前。
どうせクレームの電話がかかってくるなら、一人一人に真摯に向き合って丁寧に応対するのも良いかもしれません。
身命を賭してクレームに寄り添って慚愧に堪えぬその思いを真剣に伝えましょう。
その間に、システムは自動的に再起動し、他のクレームの電話は保留音を聞くことに飽きてきます。
慣れてくると、鼻をほじりながら「誠に申し訳ございません、今誠心誠意全力で復旧に」と喋りながらチャートを引っ張り出して手順を追えるようになります。
復旧手順RTAチャートの作り方は、珍しく潰しの効く能力になるので磨きましょう。
しっかりとしたチャート、常にチャートを見直す向上心、日々の走り込み、本番での平常心。
出てきたモグラを叩くのではないのです。モグラの出現順序を覚え、練習し、効率良く叩くのです。
さて、最近も陰謀が話題になりましたが、情報を知るものが増えれば握りつぶすことは難しくなります。
人を減らしましょう。
レポートラインは一本に絞り、その障害が起きたことになると給料が下がるタイプを相手に連絡を取りましょう。
うっかりミスからメールのCCから落とすのでも、手順書を作ったときに気が付いたら項目が無くなっていたのでも問題ありません。
残念ながら、その時不思議なことが起こって、連絡先が増えることもあるかもしれませんが、そういう時も諦めましょう。
出来ることは変わりません。
みずほ銀行の場合、A2以下の障害ランクの場合、頭取は別にニュースで初めて情報を知っても良いのです。
システム障害というから、なんか大変なことになるのです。インシデントだの障害だのは無くしましょう。
それは「予定されていた手順」なのです。
納品されたハードウェアには不備があり、雷は落ちてコンセントまで到達し、ケーブルは間違えて刺さり、ココしかないというタイミングで停電になります。
ただでさえ維持メンテの人員が足りてないのに追加機能や新規バッチが走ったりすることもあるでしょう。
チャートです。RTAチャートです。復旧RTAチャートを作るのです。
そのチャートには不足しかないかもしれません。ハードウェア故障→上司に電話、停電→上司に電話、みたいなチャートもよくあることです。電話しましょう。
それは障害ではありません。事前に探しておいたルートを走る競技です。
李下に冠を正さず。
例えカンムリが傾いてると分かっていても、問題になりそうな場所で手をあげてはいけないのです。
繰り返しになりますが、ペイグレードに応じた態度がプロフェッショナルには求められるのですが、お給料はいただきたい。
必要なのは、まず個別最適化です。あなたの仕事を減らしましょう。
余裕が生まれたら「この仕様は修正した方が」とか「週末にバッチあてるなら前の週末に復旧訓練をしましょう」とか言い出せば良いのです。
まあ、次にみずほ銀行が日曜に新規バッチを当てるときに、その2週間前の日曜に頭取を含んだS懸念の緊急対策本部を立てた訓練をするかっていうと、しないんじゃないかな。
つまり、そういうことです。
我々は、日々斧を研ぐ時間を作り、RTAチャートの更新を怠らないようにしましょう。
ヘルプデスクから雇止めで転職することになってエージェントに登録してるんだけど…どれも働ける気がしない。
そもそも上司から無能扱いされての実質解雇なわけだし、未経験可だとしてもSEなんて無理だよ…。
同僚には「ITで就職した方がいい。別に無能じゃないでしょ」とフォローはされてるけど…。
今の仕事で得た能力なんてあんまりない。エラーログ見て原因特定するくらい？ググればわかることだもんなあ。
そりゃITでの転職のほうがキャリア積めるんだろうけど、勉強や資格取得とかやる気が出ない。
あとパワハラ怖いよね。今の仕事も上司からのパワハラで病んでたし。言葉足らずでまともにコミュニケーション取れないし。ITってどこもそうなのかしら？病む人が多いらしいっていうじゃない。
贅沢なのは自覚してるけど、趣味の時間は大事にしたい…体も弱いから月何十時間も残業できないし。
理解のある彼くんがいるなら額面16万の事務職でいいんだろうけど、私は独り身。自立するしかない。
はあ。
めんどくさい。楽な仕事がしたい。
頑張りたくないのになあ。
スタックオーバーフローのユーザー会に行ってきた。Tシャツ目当てで。
メタな話は、正直あの界隈の人たち好きじゃないので興味なかったのだけど、
同じように一般参加した人がstackoverflowに質問した内容やそれを自己解決した経緯を聞くのは楽しかった。
エンジニアだったら、なんかの問題に躓いて、死ぬほどリファレンス読み込んで解決できなくて
神にもすがる思いで誰か…同僚だったり、SOだったり、GitHubに頼った経験はあると思う。
同僚に事象を説明していたら、環境差分に気づいてスルスルっと解決しちゃった体験。
サンドバッグになってありがとうといつも優しい同僚に言っていたが、最近ラバーダッキングというちゃんとした名前があることを知った。
長ったらしいエラーログから特徴的な文言を抜き出して、ググった先がGithubのissueで。
英語で続くよくわからない会話についた絵文字のGJを頼りにフィックスして結局直ってねーじゃんと失望するような体験。
kubernetesを見るがいい。よくわからないbotが90日後にやってきて勝手にissueをcloseしていくぞ。
そんな中で、技術者として真だなと思うのが技術的に解決方法を自分で見つけた人。隣の人から聞いたのはそんな話だ。
macのドック(下にあるアプリケーションのローンチバー)から消したアプリアイコンが、電源入れるたびにゾンビのように復活するので調べたら
osのバージョンアップ用プロセスがdockの配置を定義している静的ファイルを操作して勝手に元に戻していたことがわかったらしい。
osのバージョンアップ用プロセスがリブートで必ず動くことへの対応は見つけられなかったけど、事象と対症療法は何とか見つかったよとのこと。
正直かっこええなと思う。
システムのアーキテクチャがわかってて深い理解があって初めて可能になるような。
こんな方法はベンダーのマニュアルにも、どの教本にも載ってはいない。しかし、可能ではある。システム全体に対する深い知識と理解と応用力があれば。
EGFﾏﾀﾞｰ?といつも呟いている自分は、EGコンバットでいつEMPバラージにあってもいいように備えている。
そんな中、CVE-2018-1002105 の issue を読んで kube-apiserver に詳しくなろう！
は今、「kubernetes the hard way on azure」をやってて最初のCIDRによるネットワークの分割は、lucidchartでお絵描きまでして頑張ったのに
kubeconfigファイルの作成あたりは無の境地になって、。。。はっと、なんか不安になってきた自分に強くささった。
「kube-apiserver がリバースプロキシとして動作する」こともあるというアーキテクチャの理解をベースに脆弱性情報がこうやって発展するのか...みたいな。
震えるほどかっこええなと思う。
知識の深堀のために、SOが発展していけたら。そんなことを思う。
はじめてなのにconohaで、しかもOSをUbuntuにしたのがまずミスなんだけど
ブログとか見まくって最低限のセキュリティ設定はまあまあスムーズに終了
そこから
Apache入れて
Let's EncryptでSSL化して
htaccessでベーシック認証つける
というのでめちゃくちゃはまった
結局Apache入れてからベーシック認証つけるまで5時間もかかった……
公式サイトも含めて世の中のいろんな人が公開してるいろんな情報が、古かったり、間違ってたり、情報が足りなかったりして、もう本当に疲れた
とりあえず何はなくともエラーログを最初に見るのが大事という学びを得た
コーディングで詰まった時、どうすれば良いのかということを知りたいです
詰まった時というのは、デバッグがうまくいかない時、サーバがなぜか意図した動作をしてくれない時、新しい道具を使おうとしたけどなぜか動かない時、などなどそういうやつです。
自分は他のプログラマと比較してもそういう場面に直面する回数が多いと思っていて、そういう状況を最短路で打開するための行動指針や考え方の指標が欲しいと思っています。
すでに行っていることは、
のような行動です。
ですがこれらをやっていると時間がどんどん消えていって、夜始めたコーディングが朝になっていたりするので、どうにかしてもっと短時間で解決できるようになりたい。
直感としては、使用しているツールがいまいちというよりも、直面した問題をどう考えれば良いのかわからないせいで時間がかかっているような気がしています。
みなさんはデバッグ作業の際、どういうふうに検討を立てていますか？
