早稲田大学のWeb履修登録システムに障害 174
ストーリー by GetSet
負荷試験はみっちりやろう 部門より
負荷試験はみっちりやろう 部門より
saitoh 曰く、 "朝日新聞によると、
早稲田大学では今年度から
履修登録をWWWで行えるようにしたのだが、トラブル続きで結局
使用をあきらめ手書きによる登録に切り替えたとのこと。
これがお詫びのページ。
一部の学部では授業開始を1週間遅らせざるを得なかったという。
トラブル発覚が運用開始の3月20日、その後アクセス集中に対する
対策は行ったものの他のトラブルも起こって運用をあきらめたのが28日とのことである。
朝刊には載ってなかったがasahi.comに載っていた。いまのところ他の新聞のWWWページにはみあたらない。
私の母校では、4月の最初の1~2回の講義は受講登録が未了のまま
行うことになっていたので、受講登録システムにトラブルが生じたから
といって講義開始を遅らせる必要はないはずなのだが、早稲田はどういうシステムだったのだろう?"
経過補足 (スコア:5, 参考になる)
早稲田の学生です。
システム内部に近い人間ではありませんが、利用者側の立場から、今回の件でいくつか付記します(参考になるか分かりませんが)。
経過としては、登録が始まった日の直前(深夜)から、ポータルログインシステムが重くなり始め、未明には完全にアクセスできなくなりました。
そのため、大学側では当初攻撃を受けたものと判断して、対策を立てたようです(システムの防御強化と攻撃元の探知等)。その日の午後大学で講義要綱を受け取りに行った際には、こうした説明を書いた資料が同梱されていました(このあたり、対応が実に手際がよいと思ったのですが)。
その後、数日後にいったん平常通り申請システムにつながるようになったものの、不安定な状態は続き、断続的にのみアクセスが可能になった後、アクセスはほぼ不能になりました。
この間、ログインシステムにはアクセスできるものの履修申請システムにはアクセスできなかったり、ログインシステムにすらつながらなかったりと、状況は様々でした。また、お詫びのページには載っていませんが、学外からのアクセスを制限(学内からのログインのみ許可)するなどの対策も取られましたが、状況の改善には至らなかったようです(端末室の全端末のブラウザがリプライを待っている光景はなかなかすごかった)。
そしてお詫びにのページにもある通り、28日早朝にシステムの利用断念が決定され、直ちに全学生に緊急のメールが配信されました。
このポータルシステムでは、今年度からメールも使うようになったのですが、こちらのシステムは(他のシステムも落ちた)初日を除いてほぼ正常に動作していました。ひやひやしましたが、これが落ちた日には、もう・・・。
このシステムは昨年度から段階的に取り入れられてきたのですが、学生への周知と、(申請期間をずらすといったような)対策が欠けているのが、以前から気になっていました。案の定、という感がぬぐえません。
/* 関係者なので、ID取って以来初めてAC */
運用のノウハウ (スコア:4, 参考になる)
こういう期限付きのエントリをWebで行う時は、ピーク時の負荷を下げるために運用方法を考えないと・・・
例えば学部毎に申し込み開始と終了を変えて、それぞれをダブらないようにスケジューリングします。もちろん学部毎の人数も考慮して最適化しないと・・・
完全にOpenな小売りのサイトとかだとどうしようもないですけど、こういうクローズドな会員を対象とするようなシステムだと運用でいくらでもカバーできるはずなんですけどね。
今回はそれ以前の問題なのかも知れませんけど・・・
Re:運用のノウハウ (スコア:3, 参考になる)
ちなみに、別の某大学でもピーク負荷に履修登録システムが耐えない という問題があったと聞いたのだが。。。 開学2年めで4百数10人×2しか居ないのにピーク負荷に 耐えられないというふざけたシステムだったそうな。
やぱし負荷と運用では? (スコア:1, 興味深い)
事前の予想をはるかに超える接続要求が学外からあり、ポータルシステムにログインが不能となった。
その後、(ポータルログイン問題)解消後も~、と続けられていて、
(接続要求問題)解消後も~、となってる訳ではないから
これは結局の所やっぱり接続要求量を見誤ったつう事ではないかな。
無論、別件報告の物含めてソフトに問題は有っただろうし、
サーバ2台壊れ引き続きロードバランサも壊れさらにルータ設定?もおかしかったというハード障害も
どこまで本当だか解からないが有ったのかも知れないけれども。
でもむしろそれよりは4万4千人からが学外から一斉に接続可能なシステムで
端末制限ないし学部別、学年別に受付時間分ける等の運用工夫が全然見えてこないところが
ツリー元と同じく気になるところ。そういうのは今回全く無かったんだろか?
さらに言えばどんなに人数で計算して負荷に余裕持たせても、これだけの学生が
上手い例えが見つからないけれど列作って順番に毛を刈られるおとなしい羊の様にサイト上で
履修登録に必要最小限の動作だけして済ませてられると考えるのには無理あると思うのだけどなあ。
学生がそうでないと誰がそれを保障するのだろ^^;
これまた上手い例えではないけど監視なしで試験実施すれば何が起こるか自明なのと同じレベルで
一斉解放でなく事前の運用ルール工夫が必須な場合だったと思うけどなあ。
いんたあねっとでこんぴゅうたあだからあいていで、いつものその辺気にせずに何でもOKとか
考えてたのでは無いとは思うけれど。
実際の所はどうだったんだろね。
#まあ他分野でどちらかといえば競合企業所属なのでAC
やぱしプロトタイプだからでは? (スコア:1)
ところで、この程度の「プロトタイプ」を開発する期間を見積もるとすれば、いったいどのくらいになるものでしょうか?
門外漢なのであてずっぽうですが、NTT-COM や NEC だからそれなりの頭数は確保できるとして、半年ぐらいでしょうかねぇ。まさか1年はないですよね。
-- 環境負荷に配慮して言葉のオブラートを少なめにしています --
Re:運用のノウハウ(オフトピ) (スコア:1)
> こういうときには「四百数十人」と書きます。
4X0人じゃないんですか?
PCにECC Registeredメモリの利用を推奨します。
H大学でも (スコア:4, 参考になる)
履修届の提出締め切りは2週間ばかり延長されましたが、授業開始は予定通り行いました。(実は、僕はこの延長のおかげで致命的な登録忘れミスを修正できたのですが・・・)
人気の教科は抽選が行われたり、抽選にはずれた人は別の特定の授業の抽選時に優先権があったり、思ったより複雑なシステムを作っていたようです。
事前の負荷試験も何度かやっていたみたいなのですが、締め切り直前の駆け込み登録時には、相当の負荷だったのかもしれません。
人気の教科は抽選? (スコア:1)
きちんと選抜試験をして欲しいという要望はないの?
「大学の授業」でしょ?なんのために入試を受けて入ったのさ?
苦労して試験に受かった後が抽選じゃぁ…。
いっそ、入試も抽選にしたらどうよ?
# 数学は科学の女王にして奴隷
Re:人気の教科は抽選? (スコア:1)
もしどうしても受けたい講義があればモグリで受ける方法もあるし。
>きちんと選抜試験をして欲しいという要望はないの?
きちんとされたら、困る学生が増えるかも。
大学に勉強しに行くか、遊びに行くかの価値観の違いかな。
I'm out of my mind, but feel free to leave a comment.
Re:人気の教科は抽選? (スコア:1)
抽選になる代表例として、同じ授業が複数の異なる時限・曜日・教室に開催されているような授業で、あるコマの希望者が多いときは抽選によって決めていたと思います。もちろん、大きな教室に変更するなどして対処できる場合は、そうなっていました。
そういえば、一般教養授業には(不評の)「パッケージ教科制度」というのがあって、10個ぐらいの授業が文系・理系にまたがってパッケージになっていて、複数のパッケージの中から、1つのパッケージを選んで、パッケージ内の10個ぐらいの授業から、好きな6つ選ぶという制度があり、このパッケージ分けも、人気のパッケージは抽選でした(僕ははずれた)。これが履修届のWEB化に際し、どのように導入されたのか忘れてしまいました。(あまりにも不評だったので、この制度自体がなくなったのかも)
ともあれ、せっかくなのでいろいろな授業を取ろうとすると、おもしろそうな授業が同じ時間に開設されていて、結局4年間とれなかった授業もありました。もちろん、担当教官に熱望して、授業の時間を変えてもらうこともありました。(他の人には迷惑だったかもしれませんが。)抽選がなくても運悪くとれない授業は結構あります。
ただ、学部によっては抽選によって履修計画が結構狂っていた人がいたような覚えがあります。何人かは怒っていたかもしれませんが、(パッケージ教科制度を除いて)おおむね平穏に振り分けられていました。
関係ありませんが、総合大学だったので、他学部の専門教科にもエントリーできるのがおもしろかったです。他の大学でも、他学部の専門教科って参加できるのでしょうか?キャンパスが離れていると移動が大変かもしれませんが・・・。
他学部/学科授業 (スコア:1)
他学科の単位を卒業に必要な単位数として計上出来ない学科もありますけど、それは取れるか取れないかとは全然別の話。
KyaTanaka
Re:人気の教科は抽選? (スコア:1)
「多いなぁ。学生番号が奇数の人。お疲れさん」
てな具合でいきなり切る人がいました。
まぁ、必修で全学年受講可能なのに開講される数が少ないって事自体に問題があったんだろうけど。
3・4年生は優先権があったので、それが理由で卒業できないと言うことはないのですが。
Re:人気の教科は抽選? (スコア:2, おもしろおかしい)
保体のテストって(*´д`)ハァハァ
# 妄想が青空高く飛んでいったのでAP
Re:人気の教科は抽選? (スコア:1)
> 同じ「経済学序論」というタイトルでも、
> 複数の教授(または助教授・講師)で
> 複数のコマ数が設けられています。
> 抽選で落ちたらそちらを受講すればいいのです。
単位のために科目を履修したいのではなくて、
その先生の講義を聴きたい場合は…もぐる?
[udon]
Re:人気の教科は抽選? (スコア:1, 興味深い)
単位のためじゃなくて講義のために大学通ってる人にとっては、同じ科目
だからって講師が違ってもいいってもんじゃない。一般教養にしたって、
名物教授なんかはいるしね。
それに選抜っていっても、別に偏差値で決めるわけじゃないんだから。
試験と聞いて「難易度の高い学部学科」とかでてきちゃう時点で、考え
方が高校教育から抜け出せてないなぁと思えてしまうよ。
Re:人気の教科は抽選? (スコア:1)
Re:人気の教科は抽選? (スコア:1)
Re:人気の教科は抽選? (スコア:1)
Re:人気の教科は抽選? (スコア:1)
単位のためか、講義を聴くためかなんて、分けられませんよね。自分としてはいらないけど、必須科目ってのもありますし。すべての講義が単位のためだけだったら、さすがにヤバいでしょうけど。
# 他大学に行った友人に頼んで、授業に潜り込んだりしましたが、
# 出席取るような授業でも問題無かったです。(これって窃盗まがい?)
少しだけ詳細な事情 (スコア:4, 興味深い)
そして、これらの早稲田関係者に汎用JPのwaseda.jpの付くメールアドレスを1人に1つ付与し、これをログインIDとしたものです。
また、「ポータル」という名前から想像できるかもしれませんが、大学関連の情報公開や手続等を一カ所に集約したもので、他のシステム(Waseda-netメール・科目履修申請・パスワード再発行者向け情報倫理テストetc.)へのシングルサインオンを可能にし、利便性を追求したものです。
このWaseda-net関連の責任部署は教務部ITセンターですが、このITセンターは、民間企業に仕事をアウトソーシングしたり、そもそもITセンター職員には民間企業からの多数の派遣社員がいます。これは、主にコスト削減を狙ったものです(もともと学内にも優秀な人間はいますが、人数は少ないわけで…)。
少なくともWaseda-netメールに関しては明らかにBIGLOBE(NEC)のサービスを利用しています。
ポータルについても、民間企業に発注して作ったものと考えられます。
今回の障害は、大学の予算の関係もありますし、開発や運営に携わる人間が、早稲田大学のアクセス量の多さを甘く見積もっていたこともあるでしょう。
PHPやSQLを使っていますから、プログラムレベルでの出来の悪さがあったかもしれませんし、なにより、負荷を十分に減らしたり分散しきることができなかったのが最大の敗因かと。学外の端末からでも科目登録できるとか、システムを信頼しきった学部側がかなりタイトなスケジュールで登録日程を組んだので、ますます負荷を高める要因になったと考えられます。
アクセス過多でサーバより先にネットワーク機器が落ちるというのはよくある話ですが、本件の場合、先にサーバが落ちました(そしてネットワークも後を追って…)。サーバの処理能力が、必要とされる処理量に見合っていなかったようです。
ITセンターの人間が、学内の学生等の利用者の立場を身をもって理解しきれていなかったと思われます。派遣職員多いので。主な開発者も学外なので、必ずしも事情を把握し切れていないと思われます。何年も前から学内で、多くの端末を管理して事務を担当しまた研究もしてきたメディアネットワークセンター(MNC)や、比較的学内事情を理解している理工学部だったら、このような事態は想定できていたはずです。(そう、ITセンターとMNCと理工学部は別々の組織なんです....)
ギリギリになってもログインID=メールアドレスを取得していない学生もたくさん。パスワード忘れる人もたくさん。ウインドウ開きまくってボタン押しまくっている学生もいたりして。
3/20に出た「Waseda-netへのネットワーク経由の攻撃について」の掲示は、ITセンターの判断で各学部等に連絡をし、それを受けた各学部等が掲示をしたものと思われます。(早稲田大学は各学部等の独立性が高く、端末室の管轄にしてもバラバラなのです)
結局撤回されましたが(あとになってアクセスログを詳しく検証したのでしょうか)。
ログインIDがメールアドレスだったり、旧来の認証用パスワードとWaseda-netのパスワードが異なる等といった要因で、ログインに失敗した利用者が多かったために、ITセンターが不正アクセスと誤認したのでしょう。
ちなみに、3/20は科目登録開始日であり、また成績発表の日でもあり、両方ともポータルから利用できることになっていました。そんなわけで、3/20 0時ころから、成績が見られるのではないかと多数の学生がアクセスしたものと思われます。
早稲田大学の科目登録日程ですが、例年から、授業開始前におおむね終わるように予定が組まれています。
出席を取る授業は、初回の授業から出席簿が教員に渡されます。 学生の人数が多いので、希望する授業がかならずしも取れるとは限りません。抽選になる場合も多々あります。
ですので、授業開始前から科目登録を行います。
当然ながら、授業の試聴などという制度もほとんどありません。学生達は、「マイルストーンエクスプレス」や「ワセクラ」などの学生が作っている情報誌を読んで授業内容や単位の取りやすさ等をチェックし、科目登録をするのが、毎年恒例です。
一番怖いのは、システムがクラッシュしてデータが飛ぶ可能性です。
今回はデータが大消失とまではいきませんでしたが、一部の学生からは申請したはずなのにできてないという話もちらほら。 マークシートにしても書面で出した場合は、書面さえ残っていれば責任の所在は比較的明確になりますが(たとえばマーク間違いを想像してみてください)、システムのデータが飛んでしまったとなれば、何も証拠が残らない場合が普通ですから...
中途半端なIT化 (スコア:2, 興味深い)
授業要項の閲覧をWebシステムへ移行したものの、事実上不動。
授業要項を閲覧できなくては、履修登録ができません。
そこで、大学側に問い合わせてみると、
>「今は動かない、としか言えない」
という訳のわからない回答しか来ず、結局、システムが動作しているほんのわずかの時間に、データをミラーして(周囲に配布して)自衛しました。
この一件は、公知されることもなく、被害を被った学生側への謝罪もないままうやむやになってしまっていました。
早稲田はきちんとお詫びするだけマシかな、と思います。
いつ何時も、中途半端なIT化で被害を被るのは利用者側だということを、提供する側は知っておいて欲しいです。
# この一件で、大学側にいろいろ文句つけたのでAC
Linux + PostgreSQL + Apache + PHP (スコア:2, 参考になる)
『ほーら、やっぱりオープンソースだとだめじゃん』
などと (いわれちゃう|誤解される) のが一番いやだなぁ。
本当の問題は全然別のところにあるんだから。
--- Toshiboumi bugbird Ohta
Re:Linux + PostgreSQL + Apache + PHP (スコア:1, 興味深い)
件のシステムですが、科目登録開始2日後くらいに
vacuumをするためかデータベースの最適化という名目で
朝方にシステムを止めるようになりました。
昼間と夜間は混雑してたり落ちたりしてて全く繋がらないから朝方位しかログインできなかったのに…
Re:Linux + PostgreSQL + Apache + PHP (スコア:2, 参考になる)
> この規模だとPostgreSQLは厳しいんじゃないんでしょうか?
確かにその可能性は少なくないと思います。…でも DBMS の
パフォーマンスってスキーマの設計に大きく依存するもの
ですから、それなりに配慮して適宜にデータ冗長性をもたす
などすれば、結構タフに作れるはずなんですよね。
# 「理想の DBMS」はデータ構造に影響を受けてはならんの
# ですが ^^;;
記事を読む限りでは、当初からかなり複雑な処理を一気に実装
してしまった ( == 上記実装上の配慮を充分に検討する余地
がない) ことが、充分にスケールできないシステムを作る
原因となってしまったように思えるのです。
--- Toshiboumi bugbird Ohta
Re:Linux + PostgreSQL + Apache + PHP (スコア:1, 参考になる)
何も考えずに (というか RDBMS がオプティマイズしてくれるものと思って) SQL を書いていると確かに PostgreSQL では厳しくなりそうです。Oracle などの商用 RDBMS はそのあたりの懐が深いんだよねぇ。
ただ、事前にきっちりプロファイリングして SQL やテーブル構成を最適化しておけば、PostgreSQL でも全然イケると思いますよ。
// PostgreSQL 7.1 の時代に 4CPU の Xeon マシンで daily 1000万 trans over、
// ピーク時 200trans/sec over でちゃんと動いてたシステムを知っているので AC。
商用ソフトを併用するなら (スコア:1)
間に一枚トランザクション・モニタを入れて, キュー長が長くなってレスポンスが落ちたとしても, とりあえずバックエンドの処理が流れるようにするぐらいですかね. データ一貫性を考えるとデータベース部分を分散することは難しそうですし. このスループット保証という考え方は元もとは汎用機で一般的な物ですが, オープン系のWebベースシステムでも, いわゆる大規模高信頼性システムでは多く使われるようになってきています.
結局, オープンソースであるかどうかというよりも, ベストエフォートなシステムでは対応できない状況が有りうる. あるいは対応させようとすると過度な冗長性が必要になるということだと思います.
ところでフリー・商用関係なく, Linux用のトランザクション・モニタってありましたっけ?
Re:商用ソフトを併用するなら (スコア:1, 参考になる)
Re:商用ソフトを併用するなら (スコア:1)
なるほど, ORCA [med.or.jp]はトランザクション・ベースになっているわけですね.
Re:商用ソフトを併用するなら (スコア:1)
この手の脆弱性が嫌だからこういったものを作ったわけです。
汎用機屋にしてみると、こういったミドルウェアを持たずに業務システムを動かしているのを見ると、不安でなりません。
とは言え、今回はもっと入口のところでコケているんじゃないかと思うのですが。
Re:商用ソフトを併用するなら (スコア:1, おもしろおかしい)
Typing fault (core dumped)
Re:誰か解説してくれ (スコア:1, 参考になる)
CatchSEGVが何もしないようになっているので、要するにSEGVを握り潰してるだけ。
だから、こういうコードがあるという事は、このプログラムは状況によってはどんな動作をするかわからない。
だいたいこういうコードって、最初から入れるもんじゃなくて、「げっSEGV出ちまったよ。でもどこから出てるかわかんないからとりあえず握り潰すコード入れちまえ。ふむふむ。とりあえず問題なく動いてるみたいじゃん。このままでいいや~」というパターンがありがち。
簡単にわかりやすく言えば糞って事だな。
蛇足ながら書いとくと、SEGVをCatchするのが糞な訳じゃないよ。
SEGV受けて正常に処理されていると確認できる範囲のデータを保存するとか、相手のあるシステムだと正規の終了手段をとってからプログラムを終了させるという形で使われるのであれば、それはまっとうなやり方。
Re:誰か解説してくれ (スコア:1)
# rm -rf ./.
初期の混乱 (スコア:2, 興味深い)
# 日本語の勉強すっか・・・
3月20日に成績発表開始で、その日の午前3時ぐらいにはすでにシステムは飛んでいましたが、興味深いのは一部の主に文系学科で「不正なアクセスが多発したためシステムを停止しました。念のため学生はパスワードを変更してください。」のような掲示があり、想定外のアクセスが来てパニクってた様子が伺えます。
# もちろんログインできないのでパスワード変更どころじゃないのですが
早稲田には教学支援システムという、去年まで使えてたシステムがあったはずですが、今年はそれを用いないで全手動にしたのはどういう理由でしょうか。セットアップに時間がかかるとか、プライドとかかな
Re:初期の混乱 (スコア:1)
「不正アクセス~」って判断したのは一部の学部だったのですか。
全学への通知かと思っていたのですが。
そのあたり、連絡の不一致が表れていますね。
/* 文系学部所属のAC [srad.jp] */
Re:初期の混乱 (スコア:1)
うあ、ど間抜け。
ACと書きつつ、IDで書いちった。
えぇ、えぇ、笑ってやって下さい。
Re:初期の混乱 (スコア:1)
法、一文あたりはハッキリと「不正アクセス」と書いてありましたね。
連絡の不一致なのか、理工学部だけが事件後数時間で不正アクセスと断定する事を躊躇ったのか、気になるところです。
Re:とても混乱 (スコア:1)
北海道の某情報系大学では (スコア:2, 参考になる)
こっちは… (スコア:1)
連携して動くようになってたのかな?
----------------------------------------
You can't always get what you want...
このシステムのことかな? (スコア:1)
失敗知識データベース [srad.jp]にも登録してほしいものです。
nobuo * Who's gonna die first? *
Re:このシステムのことかな? (スコア:2, 参考になる)
件の大学の学生なので実際にシステムを利用しましたが、
エラー画面にWISDOM/U大学事務サービスと出ていました。
Re:このシステムのことかな? (スコア:1)
nobuo * Who's gonna die first? *
Re:このシステムのことかな? (スコア:1)
トラブルの原因は (スコア:1, 余計なもの)
Re:学生開発? (スコア:3, すばらしい洞察)
> 素直にプロにまかせろってことだ。
学生にも劣るようなプロがいっぱいいるのが問題なのでは?
そーゆーのを「プロ」と称して送り込んでくるのは正直如何なものか。
Re:学生開発? (スコア:3, 参考になる)
その一週間後に4回生。その後は一週間ごとに順次、3回生、2回生、そして最後に1回生と
来年度の新入生と繰り下げていく事により回線への負担を減らしていました。学校内の回線は
100MbitsのT3回線、外部とは複数のOC3で繋がれてますがそれでも履修登録サーバーが
落ちたり、回線が混雑して繋がらない事がたびたびありましたね。登録の日はほとんど全員が
朝の5時半ぐらいからF5の連打で繋がるまでPCの前から動きません。(朝6時から登録受け付け開始)
学生に任せられないと言う事ですが、私の学校では大学の生徒会の役員投票を全米でいち早く
オンライン化させた事で知られてます。システム設計を担当した友人は卒業後、他の大学で
オンライン選挙システムの設計顧問の仕事に就いて、現在は州選挙などのシステム設計の職に
就いています。学生でもシステムを熟知しているなら下手なプロに任せるよりいいのでは?
#自慢っぽいのでAC
違います(Re:学生開発?) (スコア:1, 参考になる)
別に学生の名誉のためとかそういうのじゃないですが。
作ったのはNTTコムウェア+NEC(+早稲田大学)です。
慎重を期すようにというのは、パスワードの漏洩に気をつけろとかそういう事を日々小言のようにいっていたにも関わらずってことでしょう。
引用した文章から学生が作ったと考えるのはいささか飛躍し過ぎではないかと。
その後の"プロに任せろ"って意見も、思い込みからの結論であってあまり意味があるとは思えません
しかし、お詫びメールやら経過報告メールが午前1時とか午前5時とかに送信されてて、振り回された大学学務科の人とかって大変だと思った次第。
Re:説明が嘘臭い (スコア:1)
> なんていわれてもそんな偶然信じられません。
ハードウェア障害は高負荷状況で発生しやすくなるのが理解できないってことでしょうか。
バグの方も、かなり負荷がかかるまでは顕在化しないものもよくありますよね。排他などのタイミング系のバグとか。
Re:説明が嘘臭い (スコア:1, 参考になる)
一部の科目が表示されない。
後期の時間割表と2時間連続以上の授業の時間割表が
表示されない。
科目検索の曜日の覧に指定無しの項目が無い等。
稼働中に毎日のようにこれらのバグ取りが行われていたようなので、
どう見ても作りかけのシステムにしか見えませんでした。
Re:教訓としては (スコア:2, 興味深い)
私大の方はちと知りませんが、国立大学ならば入札なので、むしろこちらから選別できないツラサというものもあります