IT-жахастики: розробники розповіли про наслідки legacy-проєктів, помилку вартістю $100 тисяч і раптову зупинку цілого заводу

Гелловін — традиційна пора страхітливих історій та байок. Вистачає їх і в роботі програмістів. Українські розробники розповіли DOU про робочі жахастики, серед яких телепортація до юрського періоду мобільної розробки, помилка в одному рядку коду, що мало не коштувала їм $100 тисяч і раптову зупинку цілого заводу через економію роботодавця на тестовому завданні.

Страшилка про те, як виконуючи тестове я зупинив завод


Андрій Роговський, Senior DevOps, засновник Ukrainian Scientific Journal of Emotional Intelligence Research

Ця історія трапилася тоді, коли я планував змінити роботу та якраз виконував тестове завдання для однієї компанії. Задача була проста: є стандартне середовище, куди надходили файли й за своєю внутрішньою логікою розподілялися у різні піддиректорії й глибше. Файлів багато, все дуже гальмувало. І треба було ті файли, які давніші від певної дати, перекинути в тимчасову директорію, щоб потім їх хтось подивився і далі з ними щось зробив. Усе б нічого, тільки мене ніхто не попередив, що тестове середовище, до якого мені дали доступ, насправді робоче. У компанії, очевидно, вирішили під тестове дати реальну задачу. А що? Зручно: і тестове є, і частина роботи виконана.

Оскільки я не знав, що це продакшн, запустив як тест викладання усіх старих файлів в одну директорію. Аж раптом виявився один цікавий баг: ця система маскувалася під Linux, але це був не він, а запущений емулятор на старій IBM. І там були свої внутрішні обмеження, зокрема щодо роботи з файлами. І коли в тимчасову директорію надійшло більше файлів, ніж зазвичай, і все працювало не на Linux, а на мутації, я повністю вибив з роботи апаратну ноду (хост), на якій були запущені віртуалки. Виявилось, що ця штука під’єднувалась до заводу. І таким чином я зупинив серйозне виробництво.

Усе це чи то через необачність відповідальної за це людини в компанії, чи то через бажання зекономити на тестовому завданні. Зрозуміло, далі зі мною щодо вакансії ніхто не спілкувався. Результат був вельми однозначний. Після цього досвіду можу дати колегам пораду: коли виконуєте тестове завдання, двічі перепитайте, чи точно воно не є «живим» компонентом робочої системи. Бо це може виявитись ще тією страшилкою як для компанії, так і для розробника.

Страшилка про помилку у рядку коду вартістю $100 тисяч

Володимир Рожков, Software Architect у Devlify, автор телеграм-каналу rozho)))k

Кілька років тому ми розробляли кешбек-сервіс. Люди завантажували застосунок, виконували умови, отримували нарахування й далі могли вивести гроші або на картку, або на мобільний рахунок. Паралельно ми розробляли сервіс для краудсорсингу, де користувачі могли виконувати завдання та отримувати за них винагороду. Щоб не розробляти окрему систему для виплат, вирішили скористатися кешбек-сервісом і робили нарахування в ньому. Щоб запобігти фроду та зламам, ми підготували систему лімітів, яка не давала вивести більше ніж $N за добу. Також на рахунку, з якого виводили гроші, ніколи не було великих сум, щоб мінімізувати втрати. Щодня в Slack публікували статистику щодо виплат.

Одного вечора ми виправляли помилку. Здається, користувачам краудсорсу не нараховувалась винагорода. Програміст закомітив фікс, перевірив, ніби все було гаразд. А за кілька годин нам написав клієнт і повідомив, що люди почали виводити більше грошей, ніж зазвичай. Ми швидко перевірили статистику та переконалися: справді якимось чином багато користувачів отримали на баланс більше грошей, ніж мали б. Деякі з них це помітили, вирішили, що це акція щедрості, і почали виводити кошти.

Ми швидко зупинили це та почали шукати джерело помилки. З’ясувалося, що розробник для зміни балансу написав SQL-запит на кшталт «UPDATE users SET balance = balance + 1». Таким чином ми за кожне завдання робили нарахування не тільки користувачу, який його виконав, а всім юзерам кешбек-сервісу взагалі. За кілька годин роботи наш алгоритм нарахував близько сотні тисяч доларів.

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

Страшилка про legacy-проєкт і карантин, який зіграв зі мною злий жарт

Дмитро Скороход, Senior iOS Developer в Noteworth

В одній з компаній, де мені доводилось працювати, був legacy-проєкт, написаний на Objective-C. У 2019–2020 роках я займався кодом, якого рука людини не торкалася ще з 2011 року, що в мобільній розробці дорівнює юрському періоду. Переписувати проєкт на Swift не планували, а додавати новий функціонал на Swift було неможливо з технічних причин. Тільки Objective-C, тільки хардкор.

Я почувався археологом, і в мені зародився страх, що якщо затримаюсь на цьому проєкті, то втрачу свої навички в сучасних технологіях. Я уявляв собі, як через деякий час мене не беруть на роботу в жодну компанію через забутий Swift. Я навіть взяв собі п’ять днів відпустки та витратив її на те, щоб написати власний проєкт на Swift, освіжити її в пам’яті. Вільний час я присвячував вивченню SwiftUI та Combine, сучасних архітектурних підходів на кшталт VIPER, MVVM і Coordinator, трендів машинного навчання та доповненої реальності.

Але попри все моїм страхам таки судилося збутися. У травні 2020 року, на піку коронавірусного карантину, мене звільнили. Ситуація на ринку праці була настільки складною, що часто вакансії закривали швидше, ніж я встигав на них податися. Відмови йшли за відмовами, я був нікому не потрібний. Ситуація ускладнювалася тим, що ми з дружиною виплачували квартиру в новобудові. Дружина була в декреті, я не міг знайти нову роботу, а тим часом з кожним наступним днем без доходів ми ризикували втратою житла. Тоді ми вирішили переїхати з Одеси до тещі в село в Рівненську область, щоб зекономити на оренді. Більше їхати не було куди, адже мої батьки живуть за кордоном.

Це могло б бути сумною історією, але все закінчилося гепіендом. Після двох місяців пошуків я знайшов роботу, причому на новому проєкті, повністю написаному на Swift з використанням прогресивних технологій, як-от PromiseKit, і крутих архітектурних підходів. Протягом випробувального терміну працював дистанційно з села, а потім повернувся до Києва. У Києві через деякий час я перейшов на кращі умови в іншу компанію, але й досі вдячний тим людям, які після довгих і складних пошуків взяли мене на роботу в липні 2020 року та допомогли зберегти квартиру. У жовтні 2021 року ми внесли останній платіж. Тепер у мене немає страхів, адже я знаю, що «коли ти чогось дуже хочеш, весь Всесвіт допомагатиме тобі», як писав Пауло Коельйо в «Алхіміку».

Страшилки для джунів та «жахастик-контролер» для програмістів

Сергій Журавель, Software Engineer в Absio

Знаю жахастик з роботи мого друга Максима про одну відому компанію. Там працюють лише дистанційно (і робили так ще до того, як ми сховалися по домівках від коронавірусу). Ця компанія пропонує високі рейти (наприклад, 50 доларів на годину), але пильно стежить за працівниками, що, врешті, може стати справжнім кошмаром для розробника. Кожен співробітник має поставити на свій комп’ютер програму, яка робить знімки екрана та камери, відстежує, що ви набираєте на клавіатурі, скільки разів клацнули мишкою. Оплата йде лише за години, зафіксовані через цю програму.

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

Також є кілька професійних страшилок для молодих, і почати варто з Internet Explorer 6. Ходять жахливі історії про те, як веброзробники мали підтримувати IE6, в якому все «не працювало» (насправді в ньому все працювало, просто по-своєму). А нині є ймовірність, що його дух може знову переродитися.

Нещодавно читав цікаву статтю про те, що браузер Safari має усі шанси повторити шлях IE, адже дуже відстає від реалізації сучасних API, повільно оновлюється і має «власний погляд» на деякі реалізації веб-API. Крім того, через політику компанії Apple розробники браузерів не можуть використовувати власний рушій, тому всі браузери (наприклад, Chrome чи Firefox) змушені використовувати WebKit.

А ще новачків нині часто лякають клаудом. Точніше тим, що у разі неправильних заходів безпеки є ризик отримати платіжку на десятки тисяч доларів — наприклад, від Amazon. І це справді часто трапляється. Працювати з Amazon можна почати абсолютно безкоштовно, приблизно рік тримаючи свій власний невеликий сервер. Або отримати сюрприз — рахунок на N тисяч доларів. Особливо якщо ви втратили логін/пароль чи секретні ключі. Ще новачки роблять щось не те випадково або тому, що не розібралися з best practice. Наш DevOps проводить курси із Cloud і там нерідко жартує: «От прийде наш главбух і спитає, чи плануємо ми купувати Amazon, бо рахунок великий прийшов». Щоб не забували вчасно видаляти непотрібні ресурси.

Байки про криптомайнінг і бійки на інтерв’ю

Денис Ювженко, Co-Founder у TADA

Чув я байку про одну львівську контору, де на проєкті працювали з AWS. Місцевий адмін-DevOps дав всій команді з близько 20 людей права адміністраторів. В одну з ночей хтось вирішив запустити в хмарі софт для майнінгу криптовалюти. Оскільки був налаштований Auto Scaling, то AWS почав автоматично під’єднувати все нові й нові додаткові ресурси... Врешті-решт, замовнику надійшов зранку чек на близько $20 тисяч за одну ніч. Винного так і не знайшли, а бідного адміністратора звільнили як крайнього. Хоча, може, то він сам усе й зробив.

Є ще одна весела байка, яка передається по «галерах». Це сталось більш як 10 років тому, точно невідомо, коли й де саме, але багато хто каже, що то було в Luxoft, в дебрях автомотиву.

Прийшов на співбесіду хлопець спортивної статури. Інтерв’ював його інший хлопець. У процесі співбесіди кандидат почав відповідати неправильно, або ж інтерв’юеру так здалося. Слово за слово, і почалася бійка. Перекинули стіл, порозбивали один одному носи. Чувак тоді, звісно, роботу не отримав, але з того часу на більшість офлайн-співбесід ходять по двоє інтерв’юерів з боку компанії, щоб на критичний випадок мати кількісну перевагу.

Выдуманная страшилка про ‘undefined’ is not an object

Андрій Губський, Software Architect у компанії Video intelligence AG

Когда меня попросили поделиться страшной историей, связанной с программированием, то сначала я думал рассказать о том, как разработчики во время релиза новой версии системы узнали о том, что QA-отдел провел регрессию предыдущей версии, а новую никто не тестировал. Но это не так чтобы и страшно. Затем я хотел рассказать о разработчике, у которого было открыто две вкладки с Cloud 9, в одной из них было настроено тестовое окружение, а во второй — рабочее. И о том, как этот разработчик чуть не выполнил terraform destroy не в той вкладке. Но и подобные истории далеко не редкость и напугать могут только совсем юных специалистов.

Поэтому я решил, что нужна по-настоящему страшная история. Про поезд. А начинается она с того, что один программист как-то решил поехать в другой город к своему другу. Утром он купил в кассе билет, а днем уже был на вокзале и ждал отправления. Ждать пришлось гораздо дольше, чем планировал наш герой. По расписанию поезд должен был прибыть в 14:18, тем не менее остановился только в 17:01. Когда он подъехал к перрону, было видно, что поезд абсолютно новый и, судя по всему, первый раз принимает пассажиров. Вагоны были выкрашены в черный цвет с замысловатыми узорами в виде зеленых шестигранников.

Когда программист поднялся в тамбур, то увидел, что, кроме него, в вагоне только проводник. Спустя пять минут после прибытия поезд тронулся, а затем начал набирать разгон. Программист, который смотрел в окно на удаляющийся перрон, заметил, что что-то здесь не так. Кое-что не давало ему покоя: все вещи в вагоне вели себя очень странно, они вдруг сами по себе начали перемещаться, исчезать и внезапно появлялись в другом месте, одни меняли цвет, а другие форму.

Впрочем, наш герой толком и удивиться не успел — практически сразу, как он заметил неладное, посреди вагона появился проводник и громко объявил: «Уважаемые пассажиры, — что было довольно странно само по себе, ведь в вагоне, кроме них двоих, никого не было, — хочу обратить ваше внимание, что вам очень повезло! Вы едете в экспериментальном поезде, в котором нет машиниста, а сам поезд и все его механизмы управляются искусственным интеллектом, написанным выпускниками ІТ-курсов на языке...» На каком языке был написан искусственный интеллект, сказать проводник не успел, так как в этот момент он просто растворился и исчез. А через мгновение свет в вагоне померк, послышался страшный грохот, и зловещий голос бесстрастно произнес ‘undefined’ is not an object!

Ни программиста, ни поезда с тех пор никто не видел.


Ілюстрація Аліни Самолюк.

👍НравитсяПонравилось5
В избранноеВ избранном0
Подписаться на тему «Хэллоуин»
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


43 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Орнул с прогрессивной технологии PromiseKit

Після цього досвіду можу дати колегам пораду: коли виконуєте тестове завдання, двічі перепитайте, чи точно воно не є «живим»

Все хорошо, но это не проблемы соискателя)

Когда-то коллега написал код который выбирал одну случайную запись из базы данных, что-то типа select * from products where category = ... order by rand() limit 1. В случае если запись не найдена — этот код пытался снова сделать этот же select в цикле, пока не найдет 1 товар.

Все было хорошо пока в этой категории были товары. Но потом заказчик в админке что-то поменял, в этой категории оказалось 0 продуктов и программа вошла в бесконечный цикл сожрав все cpu насколько я помню. Как мы пропустили это на код ревью тоже хз )

Не совсем про IT факап. Больше про эффективный менеджмент и KPI. Дело было в Привате в 11м
У работников отделений была метрика, без выполнения которой не видать премии: нужно продать минимальное количество билетов на автобус (так руководство пыталось привлечь клиентов к небанковским операциям). Суть метрики — количество билетов, не сумма.
В один прекрасный месяц все отделение осознало, что план они проваливают и решили продать самим себе пачку билетов между двумя соседними остановками (ну чтоб по минимуму потратиться). Так они формально выполнили план и получили заслуженную премию.
В день Х один удачливый водитель не обнаружил ни одного пассажира у себя на борту, хотя все места выкуплены. Казалось бы все супер, но весь маршрут накрылся, так как никто больше не смог купить билет из-за того что на одном промежутке все места заняты и владелец заработал мизер.
Начали разбираться, как так вышло и докопались до Привата и наехали на них. Дальше уже расследование было внутри банка и вышли на то отделение и всем устроили пи..ец.
Мы, программисты, об этом узнали из корпоративной онлайн газеты. Все ржали, хотя руководство, наверное, рассчитывало на порицание

Приватбанк який ми втратили, тепер буду згадувати цю історію кожен раз коли хтось буде втирати про те яким «ефективним» був банк коли належав Коломойському.

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

Кому цікаво — ставте тут лайк ще раз. 20 лайків — розповім історію, як Singleton без тред сейфіті фейлив роботу завода з оборотом 15 000 — 40 000 доларів за 90 секунд (в залежності від замовлень).

(ніколи не думав, що придеться повернутися на доу, але що поробиш...)

перекручені дитячі вигадки

Що ви маєте наувазі? Моя історія від початку до кінця правда.

твоя так :)

у інших — стандартні казки, які я чув ще років 10 тому :)

То фахівці наступають на ті ж граблі що й колеги старше.

уже 21 лайк. Чекаю на історію :)

Мелко :( Фейсбук тут в начале месяца 6.5 зеленых мильярдов вдребезги, и хоть бы шо ... ну, переименовываются правда.. наверно чтобы сказать: оте дебилы — это не мы были :)

SQL-запит на кшталт «UPDATE users SET balance = balance + 1»

При толковом админе в некоторых базах (постгресе) это вроде можно подшаманить, если автовакуум не прошелся через дертирид

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

Приблизно 14 років тому мене самого хотіли налякати :-)
Я вже якось про це писав тут. Мені був 21 рік, я вже закінчив універ і ми розробляли софт для пульта охоронного спостереження, який без повноцінного тестування поставили на справжній центр ДСО і виявилося, що через вади протоколу обміну, який повторює повідомлення, якщо не отримав на нього відповідь, але на попереднє аналогічне теж чекає повідомлень, а на приймаючій стороні з нашого боку просто була синхронна обробка... В нормальній ситуації то ще сяк-так працювало, але ті повідомлення збирав і генерував наш прилад «ретранслятор», який знаходився на АТС (бо канал зв’язку з клієнтськими пристроями був подібний до ADSL) і якщо з якихось причин зв’язок між АТС і ДСО переривався, ретранслятор починав генерити тонни спаму, які просто ддосили нашу апку.

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

Очевидно, що в той момент об’єкти були беззахисні. Нічого з ними не сталося, насправді, потім ми усунули ті проблеми, але, щоб «мотивувати», техдиректор видав страшилку — ви, каже, думаєте, «генеральний» буде платити зі своєї кишені компенсацію, якщо когось пограбують? Він повісить УСІ збитки НА ВАС! УУУУ!
Той Новий рік я провів з батьками, ми досі боялися, що від феєрверків почнуться хибні спрацювання датчиків і мені доведеться знову чаклувати з консолькою :-)

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

самый страшный ужас, это когда взрослые вроде бы люди, начинають додумывать подобное, не имея представления о произошедшем
а в реальной жизни, все оказывается гораздо банальнее, в виде какого-нибудь
ulimit
nofile 1024
на хосте, который ранее чудом не превышали

Добавлю свою страшную историю про стресс-интервью для интервьювера.
Дело было в одном из «лидеров рынка», проект активно стафился, и день без интервью считался праздником. Так вот, одного кандидата я помню до сих пор.
На интревью пришла женщина с весьма впечетляющим CV, кучей лет опыта и текущей позицией лида в другом «лидере рынка». Начало интервью было обычным — поговорили про опыт, про проекты. Слово за слово, дошли до технической части — даю задачку.
И тут она начинает, даже не плакать — рыдать.
К такому развитию событий я, определенно, готов не был. У меня сначала был шок, потом я пытался ее как-то успокоить. В итоге, мы сошлись на том что она попробует прийти на собеседование в другой день.
А рекрутеров я попросил собеседовать ее куда угодно, но только не на наш проект...

лол, вы гормональные диагнозы по интернету ставите?

А может — необычный?

Незрозуміло навіщо взагалі надавати якесь оточення під тестове завдання. Якщо десь є таке оточення, яке неможливо зрепродьюсити в своєму AWS чи GCP то це вже натяк на велику кількість головняка в майбутньому. Хібащо там «пропозиція від якої неможливо відмовитись» :)

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

Компанія підтримувала великий зоопарк різного софту для свого (єдиного) замовника, і працювало це все на такому ж великому зоопарку заліза. Від відносно сучасних серверів, і до динозаврів типу великих тумбочок з Dual Pentium III, якоїсь екзотики від Sun і т.п. Значну частину цього заліза вже треба було викидати, і, зважаючи на значну популярність віртуалізації, прийняли рішення постворювати віртуальні машини і попереносити це все у них.

Під віртуалки були закуплені IBM blade зі всім необхідним, і нам поставили задачу мігрувати це все у VMWare.

Довший час (як мінімум декілька місяців) все було добре. Навіть дуже добре, бо на блейдах більшість проєктів запрацювали відчутно швидше, ніж на морально застарілому залізі. Але потім, коли вже десь 90% проєктів успішно переїхали зі старого заліза у віртуалки, всі мігровані сервіси пішли в оффлайн.

Спочатку мене це не особливо напружило — shit happens, і масштаби саме отакі, коли «складаєш всі яйця в одну корзину». Була надія, що блейд пофіксають і все знову заведеться. Але так не сталося. Декілька днів наша адміни жили на роботі, на вуха були підняти всі вендори, але проблему так і не вийшло виправити.

І тоді була нарада, на котрій були присутні всі, хто займався підтримкою сервісів (програмісти, адміни, начальники відділів), на котрій нам сказали, що все, що було перенесено у VMWare — безнадійно втрачено. І наша задача — у максимально стислі терміни якось підняти ті проєкти на інших ресурсах. Сказати, що це був шок — це нічого не сказати. Частину заліза, з котрого мігрували сервіси, вже утилізували. Щодо бекапів мало хто морочився, бо перед міграцією нам довго і натхненно розповідали, як вого все класно резервується, як робляться снепшоти і т.д. і т.п.

Причина катастрофи? Я не маю достатньої експертизи щоби розказати всі технічні деталі, але суть в тому, що в угарі віртуалізації всього, що віртуалізується, сервер, з котрого відбувалося керування VMWare також віртуалізували у VMWare. Сталося це задовго до катастрофи, а катастрофа сталася, коли почалися якісь проблеми з RAID-масивом, і це все треба було перезавантажувати.

Наслідки? Декілька тижнів пішло на відновлення того, що вдалося відновити. Десь ≈10% сервісів і даних, що у них зберігалися, було втрачено назавжди. Shitstorm на стороні клієнта був 9-бальний. :) Думаю, якби у клієнта були альтернативи, цей інцидент міг би вбити компанію, у котрій я працював. Врятувало нас те, що ми були єдиною ІТ-компанією в радіусі 200 км.

бійки на інтерв’ю

вангую це був Кожаев :)

интересно только, с какой стороны :-)

преклонение запятых мастеру моё.. осссс..

Мы как-то грохнули модалку авторизации на магазине.
Пытались облегчить Мадженту, повырезали все что можно, в итоге юзеры, кто не залогинен, не могли оформить товар по подписке.
Никто не замечал это в течении трех месяцев.
Даже Selenuim автотесты это проморгали.
Оценили ущерб в $300k.

Даже Selenuim автотесты это проморгали.

фиговые тесты!

Делала девочка-индуска под присмотром продакт-оунера. Там был кейс «незалогиненный пользователь не может добавить подписку в корзину». Passed.
Кстати, никого не наказали.

Геловін, гакер, гостинг, гелпер? xD

Гемінгвей, Голівуд, Гонконг, гамбургер

Гепіенд

гандікап, Робін Гуд, Гамлет, героїн

І всеб нічого, але через те що ці неадеквати транскриптирацію міняють що кілька років, в мене вже в половині документів Sehii а в іншй половині Sergii і тепер от знову починається :)

Всі претензії до совків на януковочів-сабачників. Що G=Ґ, H=Г писав ще Павловський два століття тому, точніше, замість Ґ він вживав диграф КГ, який вигадали ще за Речі Посполитої.

Не було ніяких попередників. За совків та перший десяток років після був Sergey. :)
А потім почалось. G>H>G>H
Але я вже залишу Європейський вариіант, через G тут всім зрозуміліше бо тут є аналог імені майже в кожній країні саме через g.

Подписаться на комментарии