Аварія кращого системного адміністратора [закрита]

Я шукаю кумедних історій нещасних випадків системного адміністратора. Видалення електронного листа генерального директора, форматування неправильного жорсткого диска тощо.

Я додам свою власну історію як відповідь.

Мені було цікаво виявити різницю між командою linux "killall" (вбиває всі процеси, що відповідають вказаному імені, корисною для зупинки зомбі) та командою solaris "killall" (вбиває всі процеси та зупиняє систему, корисно для зупинки виробничого сервера в середина пікових годин і змусити всіх своїх колег сміятися над тобою тиждень).

Я керував нашим корпоративним веб-проксі, який в той час був продуктом Netscape. Під час гри в адміністраторських формах (це був веб-інтерфейс) була велика (і я клянусь, це була червона) кнопка, на якій було сказано Видалити базу даних користувача . Без проблем, подумав я. Давайте подивимося, які варіанти, які вона дає мені, коли я це вдарив. Звичайно, якщо немає варіантів, з'явиться запит на підтвердження.

Так, ніякого підтвердження. Немає варіантів. Більше користувачів немає.

Отже, підійшов до пана Соларіса Сисадміна і сказав, що я відчайдушно потребую відновлення з стрічки, на що він відповів: "Я не підтримую цю скриньку".

"А-а, приходьте знову", - відповів я.

"Я не повертаю цю скриньку. Це в моєму списку речей, які слід додати до обертання резервного копіювання, але я до цього часу ще не обійшов його."

"Цей сервер виробляється майже 8 місяців!" Я кричав.

знизавши плечима , відповів він. "Вибачте".

Багато років тому в компанії, в якій я працював, був клієнт, який здійснював нічну резервну копію їх сервера NT 4.0 на Jaz-накопичувач (як блискавичний диск з високою ємністю).

Ми створили пакетний файл, який працював як запланована робота протягом ночі. Щоранку вони збирали диск із минулої ночі з накопичувача, а перед тим, як піти ввечері, вставляли наступний диск у послідовність.

У будь-якому випадку, пакетний файл виглядав приблизно так (Jaz-диск був F Drive):

@echo off
F:
deltree /y *.*
xcopy <important files> F:

У будь-якому випадку, однієї ночі вони забули поставити диск. Зміна диска F: не вдалося (диск не в диску), і пакетний файл продовжував працювати. Типовий робочий каталог для пакетного файлу? С:. Перший раз, коли я коли-небудь бачив процедуру резервного копіювання, знищити сервер, на який він створювався.

Того дня я дізнався трохи про систематичне керування (та обробку винятків).

Джим.

PS: Виправлення? "deltree / y F: \ *. *".

root @ dbhost # find / -name core -exec rm -f {} \;

Я: "Ви не можете ввійти? Добре. Як називається БД?"

Cu: "Основні".

Я: "О".

Мені подобається, як кожен кваліфікує свою історію з "коли я був молодим / зеленим" так, ніби вони ніколи цього не повторять. Нещасні випадки можуть трапитися навіть з найбільш досвідченими профі.

Мій власний найгірший момент такий поганий, що я все одно відчуваю серцебиття ...

У нас був SAN з даними про виробництво. Критично ставиться до компанії. Мій "наставник" вирішив розширити розділ, щоб звільнити трохи дискового простору. Ви можете бачити, куди це заголовок? Він сказав, що програмне забезпечення SAN може робити це в прямому ефірі, у виробничі години, і ніхто цього не помітить. Дзвони тривоги повинні були задзвонити, але помітно мовчали. Він сказав, що робив це "багато разів раніше" без проблем. Але ось у чому річ - він змусив мене натиснути кнопку, яка сказала "ти впевнений?" Як я був новим у компанії, я припустив, що цей хлопець знав, про що він говорить. Велика помилка. Хороша новина полягала в тому, що LUN розширили. Погана новина була ... ну я знав, що були погані новини, коли я почав бачити помилки в записі диска на вікно Windows.

Я радий, що вдягнув коричневі штани.

Нам довелося пояснити, чому 1 об’єм даних зник у обідній час. Це був дійсно, дуже поганий день.

Насправді це хороший принцип - перш ніж робити щось, у чому ви сумніваєтесь, уявіть, що потрібно пояснити керівництву, якщо щось піде не так. Якщо ви не можете придумати гарну відповідь, щоб пояснити свої дії, тоді не робіть цього.

Nagios пінгендував нас одного ранку, коли в робочий час почали говорити, що він не може підключитися до некритичного сервера. Добре, похід до серверної кімнати. Це старий сервер, Dell 1650, придбаний у 02 році, і ми знали, що у 1650-х були проблеми з обладнанням. PFY натискає кнопку живлення. Нічого. Знову натисніть і потримайте його протягом п’яти секунд, щоб «увімкнути живлення» ... що перекриває захист від помилок BMC, оскільки без DRAC немає можливості перевірити журнали BMC, не ввівши живлення в корпус.

Машина запускає POST, а потім знову гине. Я стою над ним і йду, "пахну димом". Ми витягуємо сервер на його рейки, і один з джерел живлення відчуває тепло, тому PFY витягує його і збирається закрити коробку назад. Я кажу: "Ні, це не димовий блок живлення, це дим на материнській платі".

Ми знову відкриваємо корпус і шукаємо джерело запаху пекучого. Виявляється котушка індуктора та конденсатор, що-небудь здувало регулятор напруги на материнській платі, і розпорошував розплавлений мідь та конденсаторний контур по всьому, вкорочуючи купу речей і в основному створюючи великий безлад.

Найгірше для мене було те, що я визнав, що я курив достатньо обладнання, щоб визнати різницю між запахом згорілої материнської плати та згорілим джерелом живлення.

Три дні тому (серйозно) мене віддалено увійшли до шкільного сервера, встановивши Service Pack 2 на файловому сервері Windows Server 2008.

Я вирішив запланувати необхідну перезавантаження на пізню ніч, коли викладачі не будуть входити в систему оформлення карт звітів на кінець року. Я набрав щось на кшталт:

 о 23:59 "вимкнення -r -t 0" 

... що, можливо, спрацювало б чудово.

Але потім я вдруге здогадався. Чи був мій синтаксис "відключення" правильним? Я спробував переглянути довідку щодо використання, ввівши

 відключення / год 

... і миттєво втратив зв’язок RDP. Панікуючи, я натиснув Google на синтаксис. Швидкий пошук показав, що версія вимкнення версії Server 2008 включає перемикач / h, який (як ви вже здогадалися) перезимує машину.

Вчителі почали телефонувати мені протягом декількох хвилин, щоб повідомити, що вони більше не можуть відкривати або зберігати картки звітів, над якими працювали. Оскільки я був поза межами сайту і серверна кімната була заблокована, мені довелося безпосередньо зателефонувати директору школи і пройти її через процес включення машини.

Сьогодні я приніс усім домашнє печиво як форму вибачення.

У попередній роботі у нас була чудова система доморощених виробів, яка реєструвала та архівувала кожну частину пошти, яка входила, залишала чи залишалася в компанії.

Знищив всю свою поштову скриньку? Нема проблем! Шукаєте шматочок пошти, який вам надіслав хтось тиждень / місяць / рік тому, але ви не можете згадати, хто його надіслав чи що було за тему? Нема проблем! Ми просто перезавантажимо все з лютого для вас у спеціальну папку.

У якийсь момент у генерального директора компанії виникла потреба контролювати пошту, яка перебуває між конкурентом та внутрішнім продавцем під підозрою. Тож ми налаштовуємо сценарій, ніж щоночі бігали та доставляли відповідну пошту попереднього дня генеральному директору. Нема проблем!

Приблизно через місяць слово про невідкладну проблему з подвійним плюсом прозвучало з високого рівня. Здається, що, як генеральний директор читав список листів, надісланих до $ OTHERCOMPANY, він натрапив на цей:

To: somebody@$OTHERCOMPANY
From: CEO
Subject: CEO has read your message (subject line here)

Звичайно, що генеральний директор був важливою людиною, і він був надто зайнятий, щоб натиснути на всі діалоги "Надіслати читання" в Outlook і налаштував свого клієнта просто надіслати їх усім. В одному з повідомлень, що потрапив у фільтр моніторингу, було встановлено запит на читання. Здогадайтесь, що зробив Outlook? Очевидно, що посилили "підпільний" моніторинг.

Наступне наше завдання: додавання правил до поштового фільтра для блокування вихідних квитанцій про читання від генерального директора до цієї компанії. Так, це було найпростіше. :)

А-а-а, моє було близько 10 років тому, коли я ще мочив ноги. Я мав радість встановити резервні копії акумуляторів на всіх комп’ютерах програмістів. Вони також хотіли, щоб завантажене програмне забезпечення попереджало про відключення електроенергії та справно закривало.

Тому я встановив це на своєму комп’ютері, щоб спершу протестувати все і переконатися, що все працює. Тому я відключаю шнур живлення і на моєму екрані з'являється повідомлення. "втрачена зовнішня потужність, починається відключення системи".

Тому я подумав: Ей здорово, це спрацювало. Але я з якихось дивних причин навіть не пам’ятаю, що це повідомлення було надіслано як мережеве повідомлення, тому всі 200+ комп’ютерів компанії отримали це повідомлення, де 100+ користувачів, де програмісти.

Так, говори про масові виродки !!

Я ненадовго тримав голову в цьому місці!

Я часто використовував команду "sys-unconfig" на машинах Solaris, щоб скинути службу імені машини, IP-адресу та пароль root. Я був у системі користувачів, і я ввійшов на сервер встановлення будівлі і щось подивився (як root), а потім забувши, що я увійшов до іншої машини (не описовий "#" підказок), я запустив команду "sys-unconfig".

# sys-unconfig     
        WARNING

This program will unconfigure your system.  It will cause it
to revert to a "blank" system - it will not have a name or know
about other systems or networks.

This program will also halt the system.

Do you want to continue (y/n) ? y

Connection closed

#

Це повідомлення "закрито з'єднання" повільно перейшло в паніку ... на якій машині я ввійшов, коли запустив цю команду.

Найгірше це було не у важкий час, який мені дали колеги, це те, що я зробив те саме через місяць.

У мене досить гарна. Правда, це було до мого часу як систематик, але все ще пов'язаний з технікою, тому я подумав, що додам його.

Ще в той час я працював як сатком / широкосмуговий технік США. Нещодавно закінчивши технікум, я опинився в дислокуванні в Південній Кореї. Незабаром після прибуття на станцію з'явилася можливість подорожувати на південь із "великими хлопцями", які були там деякий час і фактично працювали над деяким реальним (тобто "виробничим") обладнанням.

Я зійшов з екіпажем і, як нетерплячий, молодий технік, балакав на шматочок, досить схвильований перспективою отримати мої руки на фактичному елементі обладнання, який пропускав LIVE військового голосу та передачі даних.

Щоб почати мене повільно, вони подали мені інструкцію, звернулися до секції профілактичного обслуговування і вказали мені у напрямку чотирьох стелажів, наповнених кількома великими цифровими мультиплексорами. Обладнання було досить простим, ми охопили те саме обладнання в технікумі.

Перша сторінка посібника прочитана; "Підключіть живлення до дистигального мультиплексора. Поверніть обидва задні вимикачі у положення ВКЛ. Я підняв очі, і вже застосували живлення!

Я точно опинився в неприємності. Не знаючи, як рухатись, я вистрілив з усіх сил: "Умммм. .. Щось тут програв", дивлячись на старшого.

Він подивився на мене і засміявся: "Ні, ні, це нормально. Ви можете проігнорувати цю частину контрольного списку". Потім, як він помітив погляд на моєму обличчі (оскільки нас в школі навчали НІКОЛИ, НІКОЛИ не ігнорувати будь-яку частину контрольного списку, і це була певна смерть і руйнування, якщо це потрібно зробити), він серйозно подивився на його обличчя і сказав: "Ігноруйте ТОЛЬКО цю частину! Дотримуйтесь решти, до листа!"

Прекрасно, я пробіг багатоступеневі інструкції щодо прем'єр-міністра, щасливий, як молюск, і пишаюся тим, що вони дозволяють такому низькому рейтингу (хоч і розумному) техніку робити цю важливу роботу.

Десь між п'ятим та шостим контрольним списком технічного обслуговування цих величезних мультиплексорів я почав помічати підвищений рівень активності навколо себе. Телефонували дзвінки, люди швидко рухалися. Вікторинні погляди обмінювалися.

Нарешті до мене підбігла група людей, яку очолив один із старших техніків, який мене збив.

"Гей! Ми спостерігаємо ВЕЛИЧЕЗНІ перебої в трафіку даних, і ми виділили / простежили шлях назад до стійок, над якими ви працюєте! Чи бачите ви якісь дивні?"

(У цей момент його відрізав ще один із інструкторів, що виправили неполадки, який пробрався до першої групи мультиплексорів, над якими я виконував прем'єр-міністри.)

"СВЯТІ ОРЕХИ! ЇХ ВІДКРИТИ! ЇХ ВІДКРИТИ !!!!"

Коротше кажучи, я спостерігав, як вони поспіхом пробігли перший крок в посібнику: "Поверніть обидва задні вимикачі в положення ВКЛ ..." Коли старший технік закінчився, він підійшов до мене і з недовірою запитав, що я думаю , відключивши критичні частини обладнання.

Перелякавшись розуму, я передав йому контрольний список, який я дотримувався, поклявшись, що я не відхилився ВСІХ. Щоб я дотримувався цього, «до листа», як він доручив.

Через деякий час він засміявся і вказав, де лежить проблема.

У посібнику ЗАКЛЮЧНИЙ крок у контрольному списку профілактичного обслуговування:

"Запишіть остаточне зчитування зонда, витріть передню панель, видаливши весь пил і тверді частинки, а потім поверніть обидва задні вимикачі живлення у положення OFF."

:)

Це своєрідна аварія на сисадміні. Оскільки сисадмінам періодично доводиться фізично перевозити велику кількість машин з точки А до точки В (де А і В, здавалося б, завжди розділені кількома сходами в будівлі без ліфта). Під час п’ятої подорожі дня я зупинився на перепочинок на три польоти вгору від рівня завантаження підвалу, щоб поспілкуватися з кимось, хто спускається, підперши повнорозмірну вежу з / по станції, яку я шипляв на внутрішній поруччя відкритої сходової клітки і ... ну, ви здогадалися ... трохи втратив мене в руках. Він безперешкодно поринув прямо в колодязь, а коли досяг дна, е ... не стільки з функціоналом для цього! Загальна кількість врятованих деталей: дві палички оперативної пам’яті, одна дискета та одна карта ISDN (нехай Бог благословить інженерів Hermstedt!). Все інше або тріснуло,

З ласки Божої, ніхто не ходив внизу, що, на щастя для мене, було першим моїм начальником, тому я повинен утримати свою роботу. Відчував себе дуже хворим протягом години або близько того.

Мораль: гравітація завжди перемагає!

Я перезавантажував систему для когось, і під час процесу ручного резервного копіювання я поставив йому питання "Чи є у вас інші програми, які ви використовуєте?" і "Чи є ще щось важливе, що ви робите на комп'ютері?"

Він сказав "ні" кілька разів.

Я переконався і відформатував диск.

Близько 30 хвилин він сказав "о боже мій" і поклав обидві руки на голову.

Виявляється, він працював над написанням книги понад 10 РОКІВ у спеціалізованій програмі. Це повернулося, коли програми, які використовували для збереження даних користувачів у його каталозі програмних файлів, я пропустив це.

Whhhhooooops.

Він не злий на мене, але це було тверезим почуттям.

Мій особистий улюблений насправді не мій, і я дуже радий цьому. Погляньте тут.

У мене цього не сталося, але ...

Я працював у компанії, яка виробляла програмне забезпечення, яке працювало на машинах Linux, наданих клієнтом. Ми, по суті, «взяли» на себе машини, повністю налаштували їх під наші характеристики, і зробимо все управління та моніторинг. По суті, ми були командою з 10-15 системних адміністраторів, які керували тисячами серверів для сотень клієнтів. Помилки повинні були відбутися.

Один з нашої команди знайшов деякі проблеми на сервері (резервна копія, я вважаю) і вирішив, що він повинен запустити fsck на ньому. Він зупинив усі відповідні служби, переконався, що в системі були зроблені резервні копії, зроблені нещодавно, а потім запустив fsck, але скаржився, що файлова система встановлена. Оскільки ми були віддалені і не мали віддаленого доступу (DRAC, ILO тощо), він не міг зробити fsck, але був впевнений, що це безпечно робити з встановленою файловою системою, якщо ви обережні.

Він вирішив спробувати сам, запустивши fsck на своєму кореневому розділі з передбачуваними результатами - він пошкодив свій кореневий розділ і більше не міг завантажуватися.

Розгублений, він підійшов і поспілкувався з нашою командою. Ведучий сказав, що він майже впевнений, що ви цього не можете зробити, і член команди сказав: "Звичайно, ви можете!", Взяв клавіатуру ведучого і показав йому, що ви можете - запустивши fsck на корінний розділ ведучого. Який повністю пошкодив його корінний розділ.

Кінцевий результат? Дані клієнта не втрачені завдяки тестуванню члена команди. Два дні продуктивності співробітників були втрачені, але це коштувало далеко, набагато менше, ніж дані на машині замовника. А для запису? Ви можете запустити fsck на встановленому диску, але тільки для перевірки даних. Не для ремонту. Це була помилка члена команди.

-

Щоб додати свою власну історію, я працював у тій же компанії і намагався скинути пароль користувача. Наша система відмовилася дозволити мені встановити потрібний йому пароль, оскільки він відслідковував старі хеші паролів і відмовив вас дублювати пароль. Механізм був простий: він підтвердив ваш пароль щодо останнього хешу в базі даних.

(І для запису, це повинен бути старий пароль, оскільки це спільний обліковий запис, і переконайтесь, що всі знають, що новий пароль недоцільний)

Я вирішив просто зайти в базу даних користувачів і видалити нові записи, щоб вони використовували старіші. Це все лише SQL (працює стародавня версія Sybase), тому це легко. По-перше, мені довелося знайти записи:

SELECT * FROM users_passwords WHERE username='someuser';

Я знайшов старий запис, який він хотів зберегти; перед ним було ще двоє. Я вирішив бути розумним і просто видалити все новіше, ніж старий запис. Подивившись набір результатів, я побачив, що в базі даних старий пароль був ідентифікатором №28, а новий - ID #several тисяча (дуже зайнята система). Це просто, всі старі рядки були> 28, так:

DELETE FROM users_passwords WHERE id > 28;

Немає нічого гіршого, ніж зробити просту обрізку рядків і побачити "постраждалих 212 500 рядків". На щастя, у нас було два головних сервери баз даних (з ідентифікатором користувача), але Sybase (принаймні, наша версія) не підтримував автоматичну реплікацію, тому він не вимикав автоматично старі записи. Тривіальна справа - отримати дамп таблиці user_passwords та повторно імпортувати його. І все-таки досить великий "о f ** k!" мить.

Ще один із моїх улюблених:

Під час налаштування комп'ютера та локального лазерного принтера в системі, у мене виникла яскрава ідея підключити їх як до ДБЖ комп'ютера. Коли-небудь намагалися надрукувати на локальному лазерному принтері, коли він підключений до настільного ДБЖ? Ну, якщо ви не знаєте, воно, як правило, тягне всі ампери ... Що перезавантажує комп'ютер ... І завдання друку ніколи не закінчується ...!

Коли-небудь телефонуйте: " Щоразу, коли я друкую, він перезавантажує комп'ютер і не друкує !!! '?

Ой!

JFV

ВИДАЛИТИ заяву без пункту WHERE, в базі даних живих меценатів клієнтів.

Введено kill 1як корінь. initі всі її діти померли. І всі їхні діти. тощо. На жаль.

Що я мав на увазі, це було kill %1

Після того як я зрозумів, що я зробив, я підбіг до панелі управління машини для сортування тюків BIG з вовни та натиснув кнопку аварійної зупинки. Це зупинило розрив машини на шматочки, оскільки я щойно вбив програмне забезпечення, яке ним керувало.

Ми опинилися в середині відключення електроживлення і побачили, що ДБЖ працює на 112% від налаштованого навантаження. Це не було великою проблемою, оскільки ми працювали на генераторі в той час.

Тож ми розійшлися, підтягуючи резервні силові кабелі, щоб зменшити споживання електроенергії на цьому ДБЖ (у нас було два, один набагато більший за інший). Ми дісталися до мережевого комутатора, який керував серверною кімнатою (це була серверна кімната з усіма внутрішніми серверами компанії; клієнт звернувся до серверів в іншій серверній кімнаті). Комутатор був комутатором великого корпоративного класу з трьома джерелами живлення. Поставки були N + 1, тому нам потрібно було лише два, щоб запустити комутатор.

Ми вибрали кабель і витягли його. На жаль для нас, інші два були підключені до єдиної смуги живлення, яка негайно підірвала, коли навантаження піднялося на два джерела живлення, які були підключені до неї. Потім сисадмін запанікував і підключив третій кабель. Перемикач намагався загорітися, передавши весь набір комутатора на єдине джерело живлення. Замість того, щоб джерело живлення вимкнулося, воно вибухнуло в зливі іскр, не за 12 дюймів від мого обличчя, що відсилало мене стрибати назад у стійку серверів.

З інстинкту я намагався стрибнути в бік, але, на жаль, ліворуч була стіна, а двоє праворуч були дуже великими 6'4-дюймовими хлопцями. стійок Compaq (ті, що мають тонкі сітчасті фасади), не кладучи цілого в стійку, і не торкаючись до обладнання.

У якийсь момент моєї кар’єри юридичне розслідування в компанії, над якою я працював, поставило перед нами вимогу зберігати всю електронну пошту від "цього дня" до тих пір, поки не буде сказано інше. Приблизно через рік зберігання щоденних повних резервних копій обмінного середовища (1 ТБ щовечора) у нас не вистачало місця.

Адміністратори біржі запропонували нам зберігати лише кожну 8-ю копію електронного листа. Для цього нам довелося відновлювати дні обміну базами даних, витягувати потрібний їм електронний лист (конкретні люди, позначені для розслідування) та повторно архівувати його. Вони робили це для кожного 8-го дня електронної пошти для всіх наших резервних копій. 8-й день був обраний тому, що в обміні був набір параметрів, де "видалені елементи" зберігаються в базі даних протягом 8 днів.

Після того, як вони закінчать кожен архів, я б повернувся назад і видалив усі резервні копії, які були старшими за те, що вони архівували.

TSM не має простого способу зробити це, тому вам доведеться видаляти об'єкти вручну з резервної бази даних.

Я написав скрипт, який видалив би всі резервні копії, старші за якусь дату, шляхом обчислення дати, використовуючи різницю між сьогоднішньою і цією датою. В якийсь день мені довелося видалити резервні копії, що мали приблизно місяць, за винятком випадків, коли я здійснив підрахунок дати, я написав помилку та вписав дату як 7/10/2007 замість 6/10/2007, і запустив сценарій. Я видалив цілі зайві місяці даних, випадково це було частиною дуже важливого позову.

Після цього я додав кілька кроків до сценарію, щоб підтвердити, що ви хочете видалити дані, і показати вам, що він збирався видалити ...

На щастя, вони ніколи навіть не використовували жодних даних, над якими ми наполегливо працювали, щоб зберегти, і я все ще маю свою роботу.

Після довгого робочого дня або відстеження продуктивності та налаштування величезного мейнфрейму (ви знаєте, звірі, які проходять за пару годин, перш ніж всі резервні сайти в режимі очікування погодилися, що це дійсно знову завантажилося і повністю синхронізується), я розтягнув пальці, набрав задоволене відключення -p зараз у моєму ноутбуку підкажіть, закрив кришку, витягнув серійний кабель з мейнфрейму, очікуючи приємного холодного келиха лагеру.

Раптом я чую оглушливий звук, який крутиться вниз мейнфрейм, поки мій ноутбук із задоволенням демонструє X.

Дочекавшись, коли машина знову з'явиться повністю в Інтернеті, я вирішив, що у мене є час, щоб мої ACPI працювали на моєму ноутбуці, тому я ніколи не піддався спокусі відключити свій ноутбук.

Ця аварія не сталася ... але варто згадати:

Мене відправили до центру даних, що використовується широко, щоб провести тести на пропускну здатність нового ланцюга. Я дістався до кімнати demarc / IDF, знайшов місце на одній із стелажів для мого тестового маршрутизатора, зробив зв’язки та розпочав тести. На жаль, я повністю не зміг помітити, що внутрішньовиробничий маршрутизатор не тільки знаходиться на наступній стійці (майже на тому самому рівні), але й те, що він був таким же маркою та моделлю, що і мій тестовий маршрутизатор.

Коли було проведено тестування, я почав натискати перемикач живлення у положення вимкненого (... уявіть це у повільному русі ...), і, клянусь, так само, як я чинив тиск, на мене осяялося, що маршрутизатор, про який я збирався відключити було те, що у виробництві. Моє серце зупинилося, і я майже… ну, використовую вашу уяву.

Я залишив МДФ центру обробки даних, виглядаючи розгубленим і блідим, але в той же час радий, що все-таки працював!

Я помилково видалив обліковий запис когось, імена змішалися з тим, кого я хотів видалити. Опс

Класна частина полягає в тому, що вони ніколи не знали, що сталося. Отримав дзвінок, на який вони не змогли ввійти, копійка потрапила на рахунок, який я видалив.

Під час спілкування з ними я швидко створив їхній обліковий запис, приєднав до нього стару поштову скриньку (на щастя, Exchange не видаляє поштові скриньки відразу) і повернув її до своїх старих файлів користувачів.

Тоді я звинувачував їх у тому, що вони забули свій пароль, який я щойно для них скинув :)

Випадково встановлено файл tar.gz на моєму вікні Gentoo Linux у неправильному місці, і він залишив файли всюди. Це, мабуть, було близько 1999, 19 років (спасибі за коментарі нижче)

Будучи витівником, який я є, я вирішив спробувати скриптувати себе з роботи, проходячи вручну через кожен файл.

Тому я спробував:

смола - список evilevilpackage.tar.gz | xargs rm -rf

Мені не потрібно було довго зауважувати, що tar також перераховував усі каталоги, якими користувалася програма, включаючи такі: '/ / usr, / var, / і т. Д.' 'Та кілька інших, яких я не дуже хотів піти.

CTRL-C! CTRL-C! CTRL-C! Запізно! Все минуло, перевстановіть час. На щастя, в коробці не було нічого важливого.

Як невелика частина мого колишнього життя я керував файловим сервером компанії, вітком 4:11. Навряд чи КОГО-небудь взагалі потребував будь-якого вводу, але якщо це було, ви відкрили вікно віддаленої консолі.

Я звик використовувати DOS весь час, коли я закінчив, я, природно, набрав "Вихід". Для Netware "вихід" - це команда вимкнути ОС. На щастя, він не дасть вам вимкнутись, якщо спочатку не вимкнете сервер (зробіть його недоступним для мережі / клієнтів). Тому коли ви вводите "Вихід" у консолі, вона корисно говорить: "Спочатку потрібно ввести" Вниз ", перш ніж ви можете вийти"

Запитайте мене, скільки разів я 1: набрав "вихід" у сеансі консолі та 2: Покірно набрав "Вниз", а потім "Вихід", щоб я міг "закінчити те, що намагався зробити"

А потім телефон починає дзвонити .....

Лол

Ще одна історія, яка не відбулася (феу):

Ми щодня релігійно робили резервні копії на магнітофон.

Нам трапилось написати стрічку, що містить дані, щоб переслати комусь іншому. Вони сказали, що "ми не можемо прочитати вашу стрічку". Насправді, і ми не могли. Або будь-яка стрічка насправді.

Ми купили ще один магнітофон і затамували подих, поки не встановили його.

Мораль розповіді. Завжди переконайтесь, що ви протестуєте резервні копії.

Останнє місце, де я працював, мій колега мав своїх дітей із собою в серверній кімнаті (чому? У мене немає ІДЕЯ!).

Він переконався, що вони знаходяться далеко від серверів, і пояснив своєму 5-річному віку, що він не повинен торкатися жодного з серверів і ОСОБЛИВО жодного з вимикачів живлення.

Насправді він мав їх біля дверей ... (ви бачите, куди це йде ...?)

Хлопчик не торкнувся жодної кнопки живлення сервера ... Ні, це було б занадто просто пояснити. Натомість він натиснув на КРЕСЛУ КРИШКУ, що була біля дверей ... Кнопка, що вимикає живлення на ЦІЛЬКУ СЛУЖБУ СЛУЖБИ !!!

Телефонні лінії одразу почали загорятися, цікавлячись, чому обмін, файлові сервери тощо не були доступні ... Уявіть собі, що намагаєтесь пояснити це генеральному директору!

-JFV

Я колись боровся з програмним забезпеченням для моніторингу АПК APC. Будучи невеликою компанією, у нас було декілька невеликих ДБЖ і різні сервери були налаштовані для їх моніторингу. Більшість серверів були Linux, але на деяких працює ОС Windows, і тому вони використовувались, оскільки програмне забезпечення APC - це лише Windows.

Однак у той час програмне забезпечення APC було важко зафіксовано, що ДБЖ, з якою він розмовляє, також забезпечує живлення ПК на своєму ПК! Це було не так для цього сервера, але я виявив, що занадто пізно, щоб сказати, що він зупинився. Також, на жаль, провідний програміст демонстрував партнеру продукт компанії - це веб-додаток, що працює на тому ж сервері, я не хотів, щоб програмне забезпечення APC закрилося ...

Я давав новій систематичній екскурсії програму Service Manager. Я сказав: "Якщо вам коли-небудь потрібно було зупинити цю послугу, ви натиснули б цю кнопку, але ніколи не слід це робити протягом дня". Ви ніколи не повірите, наскільки чутливою була її кнопка миші!

Через дві хвилини служба знову запустилася, і ніхто, здавалося, не помітив.

Зіткнувшись над баштовим сервером, який був укріплений за стійкою, і вдарився головою об задню частину основного маршрутизатора Cisco на моєму знизу. Таким чином, виявляється, наскільки вільно шнури живлення сиділи в блоках живлення на передній частині Catalyst 6500 .

Так. Зараз у нас в серверній кімнаті міцно на гачку. З моїм ім'ям на ньому.