Розпочався новий робочий тиждень, приносячи із собою надію нових досягнень — а також імовірність щось зіпсувати так, як це трапилося з айтівцями, які розповіли про свої найгірші моменти на роботі.
Розпочався новий робочий тиждень, приносячи із собою надію нових досягнень — а також імовірність щось зіпсувати так, як це трапилося з айтівцями, які розповіли про свої найгірші моменти на роботі.
У британського видання The Register є рубрика, де ІТ-спеціалісти діляться своїми невдачами на роботі. Ми обрали п’ять історій, які мало не коштували айтівцям кар'єри.
Перша історія від Сема, справжнє ім’я якого The Register не називає. Наприкінці 2000-х айтівець створив для свого роботодавця додаток, який він описав як «набір інструментів для міграції контенту». Програма так добре працювала, що її вирішили комерціалізувати, але для цього потрібна була система ліцензування.
«Схвильований викликом, я провів вихідні, досліджуючи асиметричні ключі та створив систему ліцензування, яка періодично перевіряла сервер, як під час запуску, так і через регулярні проміжки часу», — сказав герой історії.
З часом вирішили запустити нові функції, які вимагали більш інтенсивної роботи. Сем не зміг завершити кодування протягом робочого часу й узяв додому ноутбук, щоб попрацювати на вихідних.
У понеділок дорогою на роботу в Сема задзвонив телефон. Виявилося, програма для ліцензування не працює, і ніхто не може ввійти в набір інструментів для міграції вмісту.
«І тут мене осяяло: сервер ліцензування все ще працював на моєму ноутбуці», — сказав айтівець. Ба більше, він зрозумів, що ніколи не переносив його на виробничий сервер. Роками він спокійно працював на його ноутбуці, добре виконуючи свою роботу.
Тож коли Сем прийшов в офіс, його першою роботою було розгортання програми ліцензування на належному сервері.
Цією історією поділився айтівець, якого видання назвало Руфус. Він колись працював у британській роздрібній мережі, що пропонувала своїм клієнтам кредитні рахунки.
Щоб протестувати вебсайт, який клієнти використовували для управління цими рахунками, і внутрішні додатки, роздрібна мережа створила тестові акаунти, які Руфус і його колеги могли використовувати для проведення фіктивних транзакцій.
Ці акаунти мали імена на кшталт «Містер Тестовий акаунт шість», а їхня адреса завжди була вказана як головний офіс ритейлера, де працював Руфус. Транзакції, здійснені з використанням тестових рахунків, ніколи не оброблялися як реальні замовлення. Але кожен з акаунтів мав реальний кредитний ліміт.
«Ми повинні були пам’ятати, щоб не замовляти нічого дорогого», — розповів The Register Руфус, бо якщо тестові акаунти перевищували свій кредитний ліміт, вони не могли робити більше покупок.
Усе було добре до того, як на стіл Руфуса потрапив лист, адресований «Містеру Тестовий акаунт шість», у якому говорилося про заборгованість і потрібно заплати якомога швидше. Потім почали приходити інші листи, на які не звертали уваги й лише сміялися з того, що «Містер Тестовий акаунт шість» отримує листи.
Але одного дня рахунок «Містера Тестовий акаунт шість» незрозумілим чином зник із системи. Потім стало зрозуміло, що це через ігнорування платіжних вимог.
Як виявилося, колекторська компанія купила борг і право на його стягнення. Тоді розробники зрозуміли, їм слід було поставитися до цього серйозніше, тим паче в містера Сікс адреса їхнього офісу.
Тож розваги технічної команди перетворилася на страх, що кремезні хлопці з бейсбольними битами можуть з’явитися будь-якої миті та вимагати зустрічі з містером Сікс.
«На щастя, кредитна команда залагодила справи з колекторською компанією, — згадує Руфус. «Ніхто з колекторів не з’явився, і ми отримали новий рахунок містера Сікс».
Наступний герой Кейн, який розповів про найжахливіший досвід у його ІТ-кар'єрі. «Якби я не приймав ліки від тиску, я впевнений, що не вижив би», — сказав він.
Кейн на світового постачальника апаратного забезпечення, і його попросили допомогти менеджеру з роботи з клієнтами продати велику партію нових серверів клієнту, який був уже був не задоволений співпрацею: йому надали комутатори, які спричиняли проблеми з віртуальними локальними мережами. Але коли клієнту запропонувати полагодимо комутатори, він погодився розглянути нові сервери.
Тож одного суботнього ранку Кейн опинився в офісі, намагаючись виправити «частковий збій», пов’язаний з VLAN, через який було зруйновано значну частину реалізації SAP.
«Я вирішив показати клієнту, як вносити зміни за допомогою вебсторінок конфігурації. Мені ніколи не казали не використовувати графічний інтерфейс, тому я не бачив жодних проблем з його використанням».
Але Кейн не знав, що графічний інтерфейс був із помилками.
«У підсумку я спричинив широкомовний шторм на рівні 2, який вимкнув більшу частину мережі», — зізнався він. Тепер SAP не могла отримати доступ до свого зовнішнього сховища і, на перший погляд, виглядала абсолютно мертвою.
«Я уявив, що зруйнував їхню ERP-систему, і невідомо, скільки часу знадобиться на її відновлення», — сказав Кейн.
На щастя, інфраструктура, на якій працювала SAP, була добре спроєктована й належним чином стійка. Не знадобилося багато зусиль, щоб відновити роботу мережі та ERP-системи.
Але клієнта це не вразило, і він пішов до конкурента.
Так званий Девід працював у невеликій компанії, чий комп’ютерний комплект — вебсистеми, база даних, бек-офіс тощо — вмістився на кількох стійках у серверній кімнаті. Але компанія зростала, і цієї однієї кімнати стало недостатньо, тому вирішили перемістити все до більшої.
Потрібно було перенести все до більшого приміщення в тій самій будівлі. Крок перший полягав у тому, щоб побудувати нові стелажі в більшій кімнаті, підключивши кабелі й патчі для живлення та мережі. Другим кроком було встановлення резервних систем, де це було можливо.
Протокол прикордонного шлюзу (BGP) був використаний для того, щоб переконатися, що клієнти будуть перенаправлені в те місце, яке найкраще підходить для них, тому навіть не було необхідності в простої під час переміщення цих резервних систем.
Потім настав час перемістити єдину систему, для якої не було ніякого резервування: базу даних Oracle, на яку покладався бізнес. Для цього було заплановано стислий час простою — ніч, протягом якої Девід і його команда могли фізично перенести машину з однієї кімнати в іншу.
План йшов як по маслу — систему було встановлено, увімкнено та протестовано за кілька хвилин до того, як вікно простою закрилося.
Утомлені айтівці були щасливі й зітхнули з полегшенням — аж поки Девід, нарешті розслабившись після важкої нічної праці, не відкинувся на велику кнопку вмикання на стійці. Стійки з базою даних на ній. Базою даних, яка була лише одна. Від якої залежало все підприємство.
Почалася шалена активність, оскільки секунди відлічували до моменту, коли бізнес почне втрачати гроші, якщо всі системи не будуть працювати.
Але Девід не міг пригадати, чи все запрацювало вчасно, чи, можливо, через кілька хвилин після цього. Для нього тоді час завмер.
Що він пам’ятав, так це те, що був негайно складений план, який гарантував, що база даних також буде надлишковою, і що жодна кнопка більше не зможе перевести всю компанію в автономний режим.
Спенсер працював в урядовій установі Великої Британії на посаді «спеціаліста з підтримки/інфраструктури третьої лінії». Цей статус може здатися скромним, але цього було достатньо, щоб він з колегою опинилися на рейсі до Глазго «для виконання різних завдань у досить безпечному місці».
Виконавши все заплановане, айтівці вирішили перевірити «дата-центр» — насправді невелику кімнату, повну засобів для чищення, канцтоварів, напоїв у пляшках і комутаційної панелі CAT5.
«Ми думали, що це буде приємним додатковим бонусом», — пояснює Спенсер.
Звісно, все пішло не так. Під час прибирання кабелів вони примудрилися збити з місця оптоволоконно-мідний медіаконвертер. При падінні ця коробка розбила оптоволоконний кабель, а це означає, що їхня спроба навести лад у комутаційній панелі призвела до того, що вони щось від'єднали. Щось, що, ймовірно, було важливим.
Коли чоловіки з’ясували, що накоїли, стало зрозуміло, що вони вибрали найгірший кабель для розриву. Це був кабель ST–LC, який не є поширеними. Але Спенсеру та його напарнику потрібен був один — якомога швидше.
«Почалася паніка. Було 6:00 вечора. Усі магазини були закриті, і ми були далеко від цивілізації», — сказав Спенсер.
Хвилини цокали. Ситуація виглядала не дуже добре. «Я відчув холодний піт страху від повної безпорадності», — згадував айтівець.
І тоді його колега відкашлявся.
«Я обернувся й побачив, що він тримає кабель Святого Грааля. Я не знаю, де він його знайшов, і мені було байдуже». Але Спенсера дуже хвилювало, чи спрацює це — спрацювало — і чи зможе він встигнути на свій літак додому — встиг.
Якщо ви хочете поділитися власним факапом (навіть анонімно), пишіть на електронну пошту [email protected]. І ми щотижня висвітлюватимемо найцікавіші й найнетривіальніші історії про провали українських IT-фахівців.
