「ブラックボックス」を含む日記 RSS

はてなキーワード: ブラックボックスとは

2022-05-13

半導体設計って日本にいるとブラックボックスなんだが

シリコンウェーハの作られ方とか、露光装置みたいなのは沢山出てくるんだが。

CPUもものすごい簡単なのは出てくるが、ステップアップして少し難しいのになると出て来ない。

GPUなんてブロックしかない。


なんで設計してるの?

VS Codeみたいな定番あるの?

2022-05-03

会社で仲が悪くならないために、すげえいいこと思いついた

つの作業チップ制にすればいい

ここでもよく職場の不満日記を目にするけど、たいてい仕事が増やされたとかそういうのが多い。

なぜ不満を抱くというと、給料が変わらないからだ。

それなら、一つの作業ごとで金をもらうようにすればいい。

基本給10万、他は抱えてるタスク作業ごとに何万円、ってすればいいじゃん。

タスクが終わるなら何時間かけてもいいし、何時間休んでもいい。

これ究極じゃん。

あの人はあれだけもらってるのはタスクいから当然だ、って納得するし不満もない。

あの人は家庭の事情タスク少ないか給料も減るしみんな納得。

これでみんな納得で仲良しな職場になる。

今も使われてる「なんちゃら手当」だけにするイメージ

ベースサラリー顧客見積作成手当+顧客Bアフターフォロー手当、みたいな。

追記

手当を細分化すればするほど、不公平がなくなるね。

手当が大項目だけだと、

顧客対応手当と顧客対応手当は、規模が違うのに不公平じゃん!となる。

手当ルールを徹底的に詰めていく労力は必要だけど、

それさえしっかりできてれば、

かなりの企業内の雇用トラブルは減るのではないかな。

平等になるから

手当項目を全社員アンケートとるのもいいね

まあこれができるのはせいぜい数百人規模の会社までかなあ。

追記2>

雇用の流動化って、産業構造変化にかかわるんすね

https://youtu.be/iGZUJLjtGWo?t=213

<Q&Aコーナー>

世の中のサラリーマンってそんな同僚の給料とか仕事量とか把握して

あいつがこんなに貰ってるのはおかしい」とか「俺の給料を上げるべきだ」とか

不満を溜めて人間関係スギスさせてんの?

過半数雇用問題はそこに帰着すると思うよ。

5000円でも違ったりするとギスギスする。

中途で入ってきて、役職が高かったりすると、まず古参の平社員トラブルになる。

「なぜあいつのほうが多いんだ!」というのは、判断基準クリアじゃないからで、

そこが社長や人事担当への不満になって辞めていく。

もしそれをクリアにできれば、

究極の民主主義じゃん?ってことで書いた。

契約獲得数を壁に貼り出してるような営業会社と何が違うんだろう。

基本は同じ発想ですよ。

営業マンと開発・間接部門がギスギスするのはコミッション性と固定給制の違いも一因としてある。

バックヤードフロントコミッションにすれば、

少なくとも不公平感がなくなるかなと。

典型的には良い仕事の取り合いになり、効率の悪い仕事をやる人がいなくなる。

あとは、仕事を采配する人が大きな権力を持つので、裏でキックバックをもらって良い仕事を回すなどの行為が横行する

これは書いた直後に思った。

少人数だと談合とかが起きるのは明白で、だから全社で透明にするしかないですね。

もちろん社長取締役秘書タスクも。

あと、給与も全員オープンにすることが前提となるので、まずそこがイヤな人は入ってこないから、

だいぶ人材も選別されますね。

そういう人材キックバックとか談合を好むとは思えない、ってのはあるかも。

自分は今月これだけのタスクをやったので給与アップを希望します」

って言える人が入ってくる。

作業の難度と分量を適切に用意できて評価するタスク含めて管理出来れば理想かもね

そしてその管理者への評価が正しくできれば

そしてその管理者の管理者への(略

・・・

これを公平に達成するには、一社だけだと厳しくて、絶対ブラックボックス化する。

タスク内容を国レベルオープンソースにしないとだめかもしれない。

経理勘定項目みたいに。

あれって多少はズレても大丈夫だけど、原理原則あるじゃん

あいうかんじ。

理想業務タスクオープンソース化ですね。

オープン化されれば、転職ときに、

「A社ではこれこれタスクを〇〇円でやってました~」って実績で活動すれば、

雇用ミスマッチングがなくなる。

採用側もJD明確化できるし。

「ウチでは〇〇円ですが大丈夫ですか?」みたいな。

それこそ資本主義じゃない?

本日は良いお日柄・・・」「趣味はなんですか?」「アハハハハ…(ちいかわ)」

みたいな面接してる場合じゃない。

これがちゃん機能するなら成果主義も余裕だろう。ぜひ、仕組みを構築して展開してほしい/公正な評価ほど難しいものはない。

そこでオープンソース化ですよ。

データ母集団が1業種100社とか貯まれば、

JDに書かれているタスク募集職種でだいたい平均値に収れんしていくはず。

同業種で業務内容がめちゃくちゃ違うなんてことはないんだから

まとめたら国が基準として発表する。

これこそデジタル庁とかがやったら面白そうなんすけどね・・・

仕掛りの仕事とかどう評価されるんだろう。報酬は受注時?納品時?

リストにない未知の業務が発生するたびに単価設定と担当割りで揉め事に発展しそう。

今までになかった新しいタスクの時にどうするか、は、

まず1か月は時間給で計算するしかいかもね。

それをベースに毎月全社員で固定タスクの単金に落とし込んでいく、みたいな。

そのために、参考にできるオープンデータ勘定項目)みたいなのがあればベスト

1社員最低20項目くらいの細かさは必要かな。

50項目も抱えてれば、明らかに給料高くても誰も文句言えない、みたいな。

マッチポンプでわざと問題埋め込んでおいて、それを解決する輩が増えそう

それは固定給の現システム上でも起きてるからなあ。

しろ「この毎月発生してるトラブル解決タスクはなんですか?」と、

突っ込まれてやりづらくなりそう。

すべてガラス張りのタスクになるから、闇でやるのが好きな人はいろいろ不都合感じそう。

スキルの希少性や同業他社からの引き抜き等も考慮すると決してこんなオープンチケットシステムは成立しない

まあ実現性はともかく、

スキルの希少性」は、その人の財産になるのでは?と思ってる。

今の正社員システムは、スキルの希少性がない人ほど、転職できなくなる。

他社で使いまわせないから。

逆に会社としては都合がいい。

新卒からジョブローテさせて、スキル平準化させる。

とがった人材を作らせない。

これで飼いころしにできる。

成績表の英語数学美術体育でオール3の人材を作る。(忠誠度だけは5)

これがほとんどの会社員の、「月曜日仕事にいきたくない病」の、

遠因なのではないかな?と思ってる。

今回は、どれかを5にしてほかは2とか1でいいという案ね。

知床事故は、海上スキル5の経験者を切って、

忠誠度5の新人を作ったから起きた。

結局のところ解雇規制に基づいたメンパーシップ社員新卒一括採用するのがおかしいってことになる

タスク量を定量評価して、人事に反映させるのが上司仕事なんだけど、日本場合給料払えば定額使い放題と思ってるから、優秀な人間評価ができない。お金を稼ぐには残業。優秀かどうかは能力ではなく(時間

ある意味処女を開発して洗脳させるのが新卒採用からなあ・・・

経営者には都合がいいのだろうけど。

時間給だと、どうやって一つのタスクにかかる時間を延ばすか、にスキルポイントを振ってしまうのはあると思う。

結果として、その人の能力50%も使ってないってことになるのでは?

100%まで使えるような会社就職できたら超ラッキー

でもそれって新卒カードギャンブル

結婚も、お試し同棲してお互いに知ったほうが失敗ないじゃん。

JDを明らかにして、その人が意識的スキルをチョイスしたほうが、長期的にはいいと思うけどなあ。

LvUPでいうとDQよりメガテンシステムね。

結局のところ、正社員制度って、社会保障の一端なのよね

完全歩合制みたいなの考えたりもしてたけど、結局それやりだしたら無能が弾きだされるし、

効率最優先になって、どんどんいらない仕事が減っていく(失業者だらけになる

ってなるとほんとに社会保障周りをBI含めて厚くしていかないと、色々破綻するなと思った

AI人間仕事を奪うってのも絡めてそろそろ真面目に考えていかなきゃいけない問題でもあるんだろうけど

そう、40年間片道切符護送船団なのよ。

そろそろおかしいんじゃね?と気づいていいんじゃないかっていう。

まあ効率最優先になると、国レベルでどんな弊害が出るかもしれないし。

あくま思考実験ですけどね~。

なので10万円っていうのは、ベーシックインカムセーフティネットのつもりで書きました。

まあAIRPAが発達すると、多かれ少なかれそっち(効率優先)の方向になっていくのかと。

仕事ができなくても態度が大きいとか周りへの圧力のかけ方がうまいひとから

仕事中途半端でも終わったと承認しろと言われたらどうするのかな。

そういうことができなくさせるための仕組みづくりが、今回のアイデアって感じですね。

パワハラ恫喝って民主主義とは逆だからね。

ウクライナ戦争や台湾恫喝とかで、もう気づいたでしょ。

民主主義を捨てると何が起きるかってことが。

このパターンって社員同士がライバルになるから仕事で協力しなくなり、後輩を教育しなくなり、風通しが悪くなって失敗する

ほかの社員への協力というのもタスク化されるから、それも成果として可視化される。

あと、このモデルが仮に実践されるなら、教育必要なくなると思ってる。

だって社員全員が、中途の経験採用もの

最初からタスク内容が100%分かって入ってくるのでミスマッチがない。

教育コストも極小化できる。

面接では、業務知識テストすればいい。

風通しについては、

給与スキルデータが全社員可視化されるから、全員スケルトン状態

信長の野望とか、プロ野球選手みたいな。

誰もやりたがらないタスクは少しずつ対価が値上がりしていく仕組みとか試してみたくはある

もっといいこと思いついた!チップ金額設定で絶対揉めるからタスクごとにオークション制にすればいいんだ。

簡単コスパいい仕事ほど低額で落札される。皆がやりたくない仕事ほど高額になる。これで公平だ。

競馬オッズみたいにチップ金額決めたら面白そう。

これは思いつかなかった。

これができれば究極だよね。

明らかなブルシットジョブでも、誰もビッドしなければ値上がりして、最終的に誰かが食いつく。

MSバルマー時代にこういう評価制度を導入したら皆が自分短期的成果に繋がる仕事だけする状態になったので、ナデラCEOが「他メンバー評価に貢献したら評価ポイントがつく」という制度改革したという逸話がある

こないだのMS中の人ブログとつながった。

マネージャ自分仕事キャリアを助けてくれる」のあたり。

https://www.publickey1.jp/blog/22/1_regional_scrum_gathering_tokyo_2022.html

そんな回りくどいことよりやっちまえよ、セックス

やっちゃえ日産

2022-04-29

anond:20220429221519

おじさんの時代趣味開発であれば設計は後からついてくることが多かった

ワンアイディアへ肉を盛っていく手法が大半で、よくわからんブラックボックスが生まれる元となっていた

そういう失敗を経て設計大事さを学ぶので、趣味開発やらんと設計やりたいという気持ちも湧かないんじゃないかな?しらんけど

プログラマー以外のエンジニアもっと情報発信して欲しい

プログラミングWebは調べれば、それなりにわかる。

化学機械電気建築とか、プログラミングWeb以外ってブラックボックスに近い。

で、政治経済ネタ話題になっても、ズレた話ばかりになるんだわ。

最近だと政治家もネットで話題になっているのを聞いて動いているのか、ズレたまま動いていることもある。

2022-04-21

anond:20220421125649

たいした内容でもない仕事ブラックボックスにして難しいことやってるふりして雇用死守してそう

2022-04-09

Stage for Cinderella パドック雑感

デレマスデレステ)で今夏以降開催される総選挙……ではない、後釜イベントStage for Cinderellaのシステムへの感想とか、あとは誰が上位に入りそうかの下馬評

誰は行けそうだ、誰が本命で誰が大穴、誰は厳しいんじゃないか、そういう話題アイドル名を伏せずに出すので、そういうドラフト生みたいな話題ダメなヤツはこの時点でブラバ。いいな。俺は言ったからな。







仕組みは割愛する。簡単に言うと190人を4ブロックに分けて予選、予選上位5名+プレーオフの21名で本戦。予選上位5人x4組にそれぞれ楽曲(+声)、本戦上位5人に楽曲(+衣装SSRもろもろ+声)、本戦一位がシンデレラガール

全体の傾向

予選

CG狙い陣営ウオーミングアップ、ボイス陣営はここが本番、「CGは無理だけど曲はあげたい」って陣営はいるかも(あまり興味がない)。第7~8回ぐらいの温度感 (( 人気投票とボイス争奪戦バランスとして )) の総選挙が4ブロック開催されんじゃねえかなあという気がする。大前提として人気投票で、そこにボイス争奪戦がどこまで絡んでくるかという話だが、運営はあまり「ボイスが付く」というところをフィーチャーしたがらないし、ボイスがないキャラに無関心でもデレステは楽しく遊べるゲームなので、結局この形式では人気投票に近くなる(=声付き有利になる)……と思うのだけど、「よくわからないけど、たくさんボイスがつけられそう」とか「5票あるからボイスにも票を回せそう」という反応を自分の狭い観測範囲の中でもたくさん見かけるので、自分が思ったよりボイスへの流れがあり、各ブロック新ボイスが1、2枠、という感じになると思っている。

ボイス、8回以前は前回以前の結果や中間発表もあり「勢い」みたいなのが観測できたが、9回10回は3人固定、結果発表中間なし上位のみとかなりのブラックボックスで、しかも蓋を開けてみれば「総選挙票のついでのボイス票が大勢を決した」みたいな結果だったので、ボイスへの広報活動の手応えが得られない問題を有していた。今回はボイスへの期待感に加え、「決まった投票先がなく手持ちの票を余す人」(これまでも居たには居たが、これまでのそういう人はただボイスに関心がなかった人なのに対し、関心がある人がそのような立場になりうるというのは9回10回より健全そう)が確実に発生するので、広報活動の手応えがわずかなりとも得られる環境に戻りそうなのは素直に嬉しい所。

あと、「5人投票できる」というのが結構曲者で、自分で入れた票が推しへの妨害になりかねないというシステム的な問題がある。それを解決するために「投票しない」とか「全員に同じだけ投票する」とか「明らかに推しより上位の子に捨てる」とか「明らかに上位に入れなさそうな子に捨てる」とかい戦術が編み出されるのは当然なのだが、それが広まりすぎるとなんか途中でシステム変更とかになっちゃいそうな。そこは運営さんの腕の見せ所なのかな。

本戦

普通CG決定戦に落ち着くだろう。予選でボイスが付いた枠の子がここで善戦するとはあまり思わない。ただプレーオフからボイスなしが上がってきたなら強烈なブーストを受け5位くらいには入るだろう、予選から上がってきた子はこの時点でボイスがあるので、CG争いに興味がないがボイスに興味がある人の関心を一手に受け、更に「プレーオフから上がってきてボイス付与」という強烈な物語性を持ちうるからだ。俺もプレーオフがボイスなしだったらこの枠に入れる。

プレーオフ

順当にCGを狙える子が、ここを戦ってCG争いへというのは正直考えづらいが、何らかの物語……「この子逆境にめげず何度も這い上がって」みたいな物語を持つ子が――いるのかは知らないが――ここを勝ち上がって本戦に行く可能性はワンチャンありそう(ただそれが本戦で勝つかというと……)。そうでなければただのボイスおかわり枠。まあほ後者なんじゃないかなあ。各ブロック上位15まで発表するってすごいなと思ったが、よく考えたら全体60位までだからまり変わってはおらんのだな。

その他

属性の枠組みがなくなったのがちょっとヤなカンジではある。クール有利パッション不利じゃなかろうか?

CG予想

わがんね。ただ思うのは、なんとなくの民意として、CG二冠は避けられていたように思うのだが、10回の区切りと枠組みリセットの影響で「二冠」は全然発生しうるな、ということと、CG経験勢の勢いをあまり感じないこと。よって現時点では◎楓 。 未経験から競ってくるとすれば、○奈緒、○志希、▲美嘉、らへんかなあ。去年のPa順位的には藍子なのだが、CGになる勢いがあるとすれば美嘉な気がする。難しい。

ボイス

ワンチャンありそうだと思った候補ピックアップ

古賀小春

U149での出方次第。もし――そんなことは絶対にないと思うが――「U149では声はつかない」ということが確定したら大炎上とともにすごい勢いになると思う。いや自分で言っててアレだがそんなことは普通無いな。てか、ボイス付くなら、それは始まる前に教えてくれないと困るのだが……。もし不確定のまま本戦突入した場合死票を嫌う人たちからはむしろ敬遠されそう。

福山舞、横山千佳

U149の出方待ち、というカンジではあるのだが、もし、「小春にだけ声が付くことが確定する」みたいな事態があれば、小学生Pさんたちが奮起するシナリオはありうる。ただその可能性は弱め……かなあ……。

今井加奈

ずぅっと候補にいるのにずぅっと報われない子という印象で、今回もやはりプレーオフ圏内程度で終わるのではないかな……。「普通の子」が特徴というのは強い訴求力に欠ける……。

工藤忍・桃井あずき・綾瀬穂乃香

フリスクに声を」って多分フリスクが登場してからずっと言われていて、でも総選挙とかだと全員同時にっていうのは厳しくて、柚のボイスがサプボの呼び水になることも特になかったので……結局、地道に一人ずつしか無いと思うんだが、じゃあ票を誰に集中させる?ってところのコンセンサス応援する人たちの間で取れていない、という感じがする。過去結果的には忍がやや有望だったと思うが、それで忍が行けるかというと、決定力に欠けるような気も……。

涼宮星花

ゆかさえイベの抜擢に加え、ノーブルセレブリティpushも感じるので、要素だけ見ればすごい強そうなんだけど、素地が少なめでまだいまいち伸び切らないか……?という感じはある。お嬢様枠、から差別化ができればあるいは。

池袋晶葉

うーん、マシーナリーとも子のインパクトが強すぎて、その異常な活躍をどう評価すればいいかわかんないんだけど、順当に人気は感じるのでなんだかんだとボイスまで行けるんじゃないかなあ。あと眼鏡枠。

松本沙理奈

この間のライブもそうだがかなり公式からの(沙理奈よりはブルナポの)pushを感じる。ただなかなかチャンスを掴めず、サプボにも値しないと判断されてきたであろうので、思ったより強くねえんじゃねえかなあ……。ブルナポがあと沙理奈さんだけってのは結構長く擦られてきたというか歴史があるので、プレーオフで強い、みたいなことはありそう。

ライラ

金髪褐色碧眼で、ナターリアの相棒枠でもあり、そういうのが好きな人の票を持ってそうなイメージ。すごく強いイメージはあまりないが、もしかしたら……?

高峯のあ

このおねーさんの魅力は単純に顔面の強さなんじゃねえかなという気がするので、普通善戦はしそう。ただ辛い物好きとかにゃんにゃんにゃんとかギャップの部分が上位に食い込むだけのセールスポイントとして機能してないような印象は受ける。

藤居朋

際立った特徴はないが距離が近くてポジティブでCo詐欺結構色んな人の「ボイス無しではこの子が好き」枠に入っているイメージ。ボイスまでありそうかなー。

岡崎泰葉

割りとみんな好きだと思うが、未知数……一歩届かない、くらいの位置か。アニメPVへの期待が逆風として機能してしまわないかなあとは思っている。でもPVで蒸機公演があれだけってことはないだろうし、案外アニメで声が付くのか……?

大石

オタククールで馴れ馴れしくて機械に強い女の子が好き(ド主観)なのに加え、七海マキノとのファタモルガーナの流れもありそうで、強いだろう。ド本命読み。

メアリー・コクラン

いま一歩という感じはするが、「U149で小春千佳、舞にボイスが確定」という限定的シナリオではかなり善戦しそう。そんなことは……あるかな……いや、あるかも……。

三好紗南

いつぞやのエイプリルフール限定SSR、この度の凪背景と、かなりpushを感じる。あきらとの交流も強めの要素で、Paでボイスまでこぎつける子がいるとしたら紗南だろう、という感じ。

イヴサンタクロース

今回のダークホースとはいえ流石にダークホースで終わるか……?でも限定が三種も出るぐらいだから何かしら一定の実績はあるんちゃうかな。

というわけで俺は、CG高垣楓新規ボイスは池袋晶葉、藤居朋、大石泉、三好紗南、松本沙理奈、計5人で提出するぜ。アディオス

2022-03-29

企業セキュリティ担当脆弱性診断との向き合い方

これは、去年のアドベントカレンダーの時期に会社テックブログ寄稿するつもりだったが、少し過激だったので見送っていた文章です。

見返してみると公益性の高い内容だったので加筆した上で増田で公開することにしました。

お前は誰?

セキュリティベンダで勤務後、ユーザー企業間で何度か転職した人間です。もう現役を退いて長いですが、自身脆弱性診断の経験があります

最近ベンダコントロールや社内の小さなインシデントを片付けるCSIRT業務しかしていません。

外注脆弱性診断が抱える問題

クライアント目線ではベンダ側がブラックボックスなのでちゃんとチェックしているのかわからない。

例えば、脆弱性はありませんでしたという報告書を提出された場合、それを信じるしかない。

ちゃん報告書の質を見なければいけないが、予算を確保するのに精一杯でそこまでできている企業は少ないだろう。

以前、イ〇〇〇社を重宝していたが、あまりにも報告書品質のブレがひどいので、現役診断士の知人に相談したところ、イ〇〇〇社はエンジニアの実績を売りにして営業をかけているが、実際には下請け会社が診断を実施しているケースも多く、社内のエンジニア担当していない案件も数多くあるとのことであった。また、学生バイトが診断を担当することもあるらしい。下請けに流すのは、この会社だけの問題ではなく、大きな診断会社では結構やっている話らしいが、個人的にはかなり驚いた。

私が過去に在籍していた企業では行っていなかったと思う(知らないだけかもしれないが)....

このように実績が多そうな会社に依頼したところで、実績が多い人がやってくれる確証はない。

依頼側はどうすればいいのか

社内に報告内容を見極められる人を置く

報告書の内容が正しいかどうか分からなければ、報告書品質を見極めることはできない。

社内に脆弱性診断経験者がいれば、その人を担当にするのがいい。いなければ雇ってもいいだろう。脆弱性診断は一件あたり数百万かかるのでそれだけの価値はある。

まりにも報告された脆弱性が少ない場合は、重要機能だけ社内でダブルチェックをするくらいのことはやるべきである

コンペを行う

同じアプリケーション複数企業脆弱性診断にかけると、出てくる脆弱性にどれだけ差が出るのか検証することができる。

脆弱性診断はただでさえ高いのに5倍くらいの金額がかかってしまうので大企業しかこの手は使えないがおすすめである

その際にコンペであることはベンダに伝えてはならない。伝えてしまうとその時だけ凄腕のエンジニア担当するだろう。

また、差を見る際には総合件数ジャッジするのではなく、影響度の高い脆弱性件数ジャッジするべき。

少数精鋭の企業に依頼する

特定ベンダに肩入れしたいわけではないので名前は伏せるが信頼できる企業存在する。

実績を売りにしている少数精鋭の企業であれば、技術力に誇りをもっているので、がんばってくれるケースが多い。

個人に依頼する

インターネットで実績を確認できるエンジニア個人脆弱性診断を依頼するのも一つの手だ。そうすればベンダに依頼した場合とは異なり、間違いなくその人が脆弱性診断を行ってくれる。共通の知人やスカウトメールを通して脆弱性診断やってくれませんか?とお願いすればやってくれる場合もある。

まとめ

セキュリティベンダベンダが作り出したWebページを見て、なんとなく信用して依頼するのではなく、依頼する側で見極める力を持たなければならない。

というか外注より内製するべき。コンペする金があれば余裕でセキュリティエンジニアを雇えるだろう。

ネットワークへのペネトレーションテストだとまた話が違ってくるのだが、この増田が伸びれば新たに筆を取ろうと思う。

2022-03-26

anond:20220326112739

そして管理職の選定プロセスブラックボックス化すれば差別があったとしてもバレることは無い

2022-03-06

anond:20220306101129

彼女がイクと愛しくてたしかにある種満足する。でもその後自分もやっとゆっくりイけるし、それがないってのはなかなか理解できないな。

元カノは、やっぱりはずかしいのか、一緒にイきたいらしくて、早く入れてって言うんだけど、それだとこっちが安心できないんだよね。

から今の彼女はほんとに相性よくて、手マンでイかしたあと、安心してこっちもイける。なんなら彼女は2回イく。

でもそれは「相性」っていうブラックボックスじゃなくて、秘訣は「話し合う」ことだと思う。今の彼女ともいろいろぶつかるけど、いつも話し合って解決してきた。

2022-02-22

https://anond.hatelabo.jp/20220217125115

黒羽刑務所の中刑務官アスペルガーになるように作って出所させた。それより以前、幼少時から知能指数が高かったという事実はない。

   あった事実としては、東大法学部生だったが、卒業前に増田事故に遭い終わったということ。その後はほとんどゴマカシ。最悪な状態発見されて捕まり

   刑事施設というブラックボックス複数刑務官アスペルガーと完全にダメなようになるように作って外に出した。

2022-02-21

カーリング選抜制を考えてみる

是非はともかく、やるとしたらこうなるんだろうなという予想。

1.メンバーの入れ替えは原則年1回

まずこれが前提事項となる。今回女子金メダル取ったイギリスのチームは、1年前とはメンバーが2人入れ替わっているが、半年前の世界最終予選とは同じメンバーだ。

カーリングは春後半~夏がシーズンオフになるので、その間に人を入れ替えることが度々行われる。五輪を契機に大きなガラガラポンが行われることが多いが、年1のシーズンオフでも1~2人くらいの入れ替えは時々ある。

一方、サッカーみたいに試合ごとに代表選抜して入れ替えると言うことは、そのイギリスでも行っていない。例外は、メンバーがケガして競技不可になった場合の補充だけだ。

2.国内強化が難しくなるので、強化は原則海外遠征

選抜制の弊害ともいえるが、イギリス中国国内試合が出来る環境にない。相手ほとんどいないからだ。言い方は悪いが、選抜から漏れた残りの人達をかき集めてチームを組んでもロクなチームはできない。そんなチームにスポンサーはつかず、まともに活動することも困難。そのため、選抜制の場合必然的海外にずっと出て強化することになる。

3.代表選出プロセスブラックボックス化して批判の嵐になる

今のクラブチーム制は、代表選定のプロセスとしては非常にガラス張りである日本選手権で良い成績を収めたチームが代表決定戦に集い、その中で最も良い成績が得られたチームが代表になる。納得するかどうかはともかく、プロセスとしてはとても明確でガラス張り状態だ。

選抜制だとそういうことは現実的に困難。

それ以上に問題なのは代表選出に対して批判の嵐になる事が不可避なこと。

常に20人以上代表が選ばれるサッカー代表でさえ毎回「なんでこの人がいるんだ!(最近の事例では長友選手など)」「スポンサー枠じゃないかコイツ!(事例多数)」「この人は監督愛人枠だね(森保監督広島時代の教え子だった佐々木翔選手に対する揶揄)」と騒がれる傾向にあるのに、4人か5人しか枠が無いカーリングでそんなことをやったら「コイツ枕営業したのか!」という下衆な勘繰りが大流行してしまうのがオチだ。枕を実際にはやっていなくても、タブロイドメディア放火してくることは避けられない。「カーリング娘」とか「クリスタルジャパン」とか「そだねージャパン」ではなく、「枕ジャパン」と呼ばれるようになるだけだ。

それを回避する策はない。

候補20人くらい選んで、その中から4人選ぶ方式で多少の緩和は考えられるが、20→4の段階で結局同じ事が起こる。20人を5チームに分けて決定戦やるという手もあるが、それだと今のクラブチーム制と実質的に変わらないか選抜制にする意味がない。

別の切り口では、イギリスがやってるように「スキップに選ばせる」という手があるが、そのスキップが集中放火されるだけだ。

4.まとめ

サッカーのような選抜制を想定して「カーリング選抜制にしろ」と言っている人に対して、「あなた想像している選抜制とは全く違うものになるよ。サッカー選抜制の悪いところだけは受け継がれるが」とだけ言っておく。

2022-02-09

anond:20220209141007

日本以外でもあるだろうけど、日本特別多い、ということを考慮すると、

「丸投げ」をしたがる日本気質適応した反社ビジネスということが言えるのかもしれない。

商品の中身をブラックボックスにできるからね。アサリ偽装とやってることは同じ。

2022-02-04

anond:20220204184810

とりあえず物理版の人に馬鹿って言われなくなればいいかなと思ってるから物理板の人の基準と同じということになるね。

そういう意味では馬鹿言葉の中身は俺にとっちゃブラックボックスだね

2022-01-31

anond:20220131120129

職人裁量が極めて大きくて、ブラックボックス部分も多い

ソースが見れてもいちいちチェックするのはコストがかかる

中身が正常かどうか個人客は分からないんだな

100万円支払ってすっからかん商品を渡されるかもしれない

2022-01-26

Laravel一歩目を踏み出す前に盛大につまづくの巻

イケてるエンジニアもすなるLaravelといふFWを、底辺チンカスエンジニアの私もしてみむとてするなり。

https://readouble.com/laravel/4.2/ja/quick.html

最初にComposerを使用し、Laravelインストーラーをダウンロードします。

フレームワークとか逆に難解すぎてやってられねーよ!と今まで拒否し続けてみたものの、なんか人気らしいので気になったんですよ。

で、公式サイトクイックスタートを見たら、1行目からこれですよ。

Composer? アホかと。バカかと。お前らな、依存管理如きで余計な要素を増やしてんじゃねーよ、ボケが。

名前は知ってるが使ったことないし、ちょっとググってもよく分からない。分かろうとも思わない。思えない。もともと頭が悪い上に中年なので学習意欲もわかない。

終わりです。終わりました。ハードル高すぎるんですよ。

Composerで手軽にインストール

って、Composer自体が手軽じゃないんすよ。

ComposerだのAnsibleだのDockerだの超絶魅力的だけど全然意味わかんないっすよ。俺くらいのバカでも分かるように作って欲しいんすよ。

結局フレームワーク使って何かハマった時にブラックボックスすぎてかえって面倒なことになるので(≒言い訳)、俺はこれから自作FWでやっていきます

それでも個人でいろいろ開発して全然困らず食っていけてるので(≒言い訳)。

結論をまとめるとPHP最高!ってことです。

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2022-01-21

勤続年数の短い人間個人情報を触れさせたくない上司

上司はしっかりとしてた上司で、二人体制でやる以上はどちらも一定水準の仕事が出来るようにと調整してくれていたが

今の上司経験が浅いやつに個人情報なんて触れさせない!!!というタイプなので、特定業務が完全にブラックボックス化してる

一応上司にも数字のものは上がっているが、どう計算した結果なのか。過程を知らないので脳死で判子押してるのとほぼ同義

じゃあ個人情報はしっかり保護されているのかと思えばそうでもなく

自体はあるが、開けようと思えば誰でも開けられるのでほとんど鍵の意味なし。べつに他人給与とか見てもしょうがないが

困ったらとりあえず片方に話を振る。そして片方と上司の間でやり取りが始まるので、自分が居る意味なし


人材大事にしよう!誰か一人の責任ではなく皆の責任!!と理想だけは立派なのだ

言ってることと、やってることの乖離がすごいので言葉けが虚しく響く

誰にも共有せずに一人で仕事抱え込んだ時点で、そいつが全責任を背負うのが普通なんすよ現実って


まあべつにいいんだけど、転職して今の地位に居る上司が一番そのことを分かってないのはなんか面白いなって思う

緩やかに現状維持・衰退したい人間はそれでいいのかもしれないけど、俺みたいにキャリア意識してるやつは他所へ行くよ

俺が信用されてないのもあるんだろうけどね。でも話し合いにすら参加させてもらえないって、そういうことなのかなって思うよ

場合によっては取引先と最前線でやり取りするのに、営業部新人ですら持っている名刺を作ってもらえないのが俺

会社行事幹事役として他よりも正装が必須なのに、会社採用してる刺しゅう入りジャケットすら貸与してもらえないのが俺

そんな無能が、俺

2021-12-24

なんで日本って製造するための設計ソフトも、物理シミュレーターも発展しなかったんや?

市場規模製造業の方が大きかもしれないけれど、設計ソフトがないと物が作れない。

使用する各社の要望を聞いていくと、各社のノウハウが集まって次第に強くなる。

アカデミックの高度な理論を、産業に落とし込むという意味合いもある。

今の日本大学が陥っている、研究者研究したいが産業に結びつかないで金が回ってこないという状況も少しはマシになっていたのではないか

(論文を書き通ったとしても、金を稼げるところを英語圏に握られているので、税金を使って相手を有利にしているだけ、になっている)

プログラムコードに起こすというのは、難しい理論ブラックボックス化して誰でも使えるようにするのと同時に、先端研究結果を広める意味合いもある。

1つの論文対応するコードだけだと断片的過ぎるのを1つに統合することで金を生み出す仕組みが必要ではなかっただろうか。


国防観点だと、原子力発電推進と宇宙産業はいつでも武器を作れる技術があるぞ、という牽制意味合いもあったのと同じ論理で、

設計ソフト物理シミュレータ必要なはずである。ないと作れないのだから


フランスは、アメリカ下僕にならないように持ってるし。

(昔からあるフランスアメリカいからだろうが)

2021-12-14

余白への問い

匿名掲示板的なものは、悪口や陰口や不満の掃きだまりになりがちだけど、本来的に期待できるのは「余白」になり得る懐の深さだと思う。

教科書的な解答、学問的な正解、社会一般的な正論は、しかるべきところを調べれば情報があるはずで、それ以外に残されているブランクスペース、美しく整理された部屋の中の、なんだかよく分からない物が集まっているブラックボックス

そこでは個人から発せられた問いに、一か八かで思いもよらないクリエイティブな解や、視点を変えるためのヒントが投げ返されてくる。考えることや作ることは、脳の中の余白、関係性の中の余白があることが大切なはずだから

2021-12-12

anond:20211212121316

初期スタッフが辞めて、中身がブラックボックスすぎて改善が出来ず、超会議みたいな外ヅラ良くする事しか出来なかった事と、

クリエイター達にタダで作らせてたのがyoutube金銭報酬システムによって一気に引き抜かれたって感じ。

2021-12-09

anond:20211209051057

お前が返してなさそうなトラバはまだまだあるけどな

でも証拠見せる過程でどうしてもリンク貼らなければならないがそれって塩を送るようなもんだから

せいぜい自分で探せよ

たとえば話が戦争とかブラックボックスに変わって以降のところにある

2021-12-07

anond:20211207184355

戦争会社抽象的なイメージが違うから会社の方がブラックボックス

戦争戦争とは、兵力による国家間闘争

会社営利目的とする社団法人

抽象的→具体性を欠くさま。物に即して考えたり述べたりしないさま。

イメージ→心に思い浮かべる像や情景。ある物事についていだく全体的な感じ。

ブラックボックス利用者が内部構造動作原理を知らなくても支障がない設計装置ソフトウェアシステムなどのこと。

 

翻訳すると、「兵力による国家間闘争と、営利目的とする社団法人は、具体性を欠いた心に思い浮かべる像や条件、全体的な感じが違うから会社の内部構造動作原理を知らなくても支障がない」

 

???

  

まりワクチン正義ワクチン信者正義

ワクチン正義ワクチン信者正義、これは掲げる正義が違うから、どっちにも分があると言う理解ができないでもない。しかし前の文との関連性が分からず「つまり」で繋げる意味が分からない。

 

まるできれいなモスバーガーの食べ方の文章を読んでいるようだ。

anond:20211207184027

いい会社と悪い会社というのはパッとみでは分からない

ブラックボックス化されているか入社するまで分からない(仮に分かっていたとしてもそれはフィードバックによるものが多い)

しか戦争というのはイメージでもうすでに殆ど現代人では戦争に良いも悪いも無いというイメージで固まっている

からリスク理解せずに売春に手を染める女を馬鹿にするのと同じで先に影響やリスク考慮せず戦争に加担した人間馬鹿だということだ

ログイン ユーザー登録
ようこそ ゲスト さん