DEV Community: Serguey Shinder

«М'які» навички стали найтвердішими

Serguey Shinder — Fri, 28 Aug 2026 20:26:05 +0000

Ми довго називали їх «м'якими» навичками — спілкування, ясність думки, уміння працювати з людьми — ніби вони другорядні поряд із «твердими» технічними вміннями. Я думаю, ця назва застаріла. У світі, куди приходить ШІ, саме ці навички стають найтвердішими, тобто найважчими для заміни й найціннішими.

Логіка проста. Технічну частину — написати код, налаштувати конфіг, знайти помилку — машина робить дедалі краще. Те, що колись вирізняло інженера, стрімко дешевшає. А те, чого машина не робить, виходить на перший план: зрозуміти, чого насправді хоче людина за розмитим запитом; пояснити складне так, щоб рішення ухвалили; узгодити людей, які тягнуть у різні боки; взяти на себе відповідальність, коли щось пішло не так.

Це не «м'яке». Це надзвичайно важко, і цього не автоматизуєш. Модель може написати функцію, але не може провести напружену розмову, вибудувати довіру чи відчути, що замовник просить не те, що йому насправді потрібно. Саме тут тепер живе людська цінність — не в тому, щоб виробляти, а в тому, щоб розуміти, пояснювати й вести.

Я бачив блискучих технічно людей, чия кар'єра застрягала саме тут: вони вміли все, крім як донести це до інших і працювати в команді. І бачив менш віртуозних технічно, які злітали, бо вміли слухати, пояснювати й об'єднувати. Раніше цей розрив був важливим. Тепер, коли машина забирає рутинну технічну частину, він стає вирішальним.

Тож не зневажай «м'які» навички як щось другорядне. Вкладайся в них так само серйозно, як у технічні, — бо саме вони залишаться твердими тоді, коли решту зможе зробити машина.

– Serguey Shinder

Найкраща метрика — це довіра бізнесу

Serguey Shinder — Fri, 28 Aug 2026 20:20:54 +0000

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

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

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

І навпаки: одна прихована проблема, одна невиконана обіцянка, одне «все добре» напередодні збою — і рахунок швидко порожніє. Довіру важко заробити й легко втратити, і жоден показник безвідмовної роботи її не поверне, якщо люди перестали вірити твоєму слову.

Тому я стежу за uptime, але дбаю про довіру. Бо команда, якій довіряють, отримує ресурси, вплив і право голосу там, де це важливо. А команда, якій не довіряють, навіть з ідеальними графіками залишається тими, кому кажуть, а не тими, кого питають. Найкраща метрика — не на панелі. Вона в тому, чи вірять тобі люди.

– Serguey Shinder

Не збирай дані, які не готовий захищати

Serguey Shinder — Fri, 28 Aug 2026 20:15:42 +0000

Є спокуса збирати все. Диск дешевий, дані здаються цінними, а раптом колись знадобиться. Тож ми логуємо все, зберігаємо все, збираємо кожне поле «про всяк випадок». Але кожен байт даних, який ти зберігаєш, — це не лише актив. Це ще й відповідальність, і одного дня вона може стати тягарем.

Бо дані, які ти зберігаєш, ти зобов'язаний захищати. Кожне поле персональної інформації — це те, що можуть викрасти, злити, використати проти твоїх користувачів. Що більше ти зібрав, то більша мішень, то більша шкода, коли щось піде не так. Дані, яких ти не зібрав, неможливо викрасти. Найбезпечніша інформація — та, якої в тебе немає.

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

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

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

– Serguey Shinder

Інфраструктура має бути описом, а не спогадом

Serguey Shinder — Fri, 28 Aug 2026 20:10:31 +0000

Довго моя інфраструктура жила у двох місцях: частково на серверах, частково в чиїйсь голові. Хтось колись усе налаштував вручну — клацнув тут, ввів команду там — і воно працювало. Але як саме воно влаштоване, чому саме так, і як відтворити його з нуля, не знав ніхто повністю. Інфраструктура була спогадом, а спогади стираються.

Проблема виявляється в найгірший момент. Сервер помирає, або треба підняти таку саму копію, або людина, яка «все пам'ятала», іде — і ти лишаєшся з системою, яку ніхто не може відтворити впевнено. Ти відновлюєш її здогадками, крок за кроком, наближаючись до оригіналу, але ніколи не будучи певним, що все точно так само.

Ідея інфраструктури як коду вирішує саме це. Замість того щоб налаштовувати вручну й сподіватися запам'ятати, ти описуєш бажаний стан у файлі. Скільки серверів, як налаштованих, з якими правилами. Цей опис — не клацання — стає єдиним джерелом правди. Хочеш відтворити систему? Застосовуєш опис і отримуєш те саме, щоразу.

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

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

– Serguey Shinder

Переносимість важливіша за зручність

Serguey Shinder — Fri, 28 Aug 2026 20:05:20 +0000

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

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

Я не кажу ніколи не користуватися зручними сервісами. Іноді виграш реальний і вартий прив'язки. Але це має бути свідомий вибір, а не випадковість. Питання, яке варто ставити щоразу: якщо доведеться піти, наскільки це буде боляче? Якщо відповідь — «майже неможливо», ти щойно віддав частину свого майбутнього чужим рукам.

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

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

– Serguey Shinder

Резервна копія — це і твій захист від шифрувальника

Serguey Shinder — Fri, 28 Aug 2026 20:00:09 +0000

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

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

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

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

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

– Serguey Shinder

Спокій під час збою — це результат підготовки

Serguey Shinder — Fri, 28 Aug 2026 19:54:58 +0000

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

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

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

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

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

– Serguey Shinder

Ценнее становится тот, кто связывает системы, а не тот, кто знает один инструмент

Serguey Shinder — Fri, 28 Aug 2026 19:54:49 +0000

Будущее нашего дела принадлежит не тем, кто знает один инструмент в совершенстве, а тем, кто понимает, как системы связываются друг с другом.

Глубокое знание одного инструмента — ценно, и я не спорю. Но у него есть уязвимость: инструмент можно заменить, автоматизировать, обесценить новой версией. Тот, кто определил себя через один продукт, стоит ровно до тех пор, пока стоит этот продукт. А в нашем деле ничто не стоит долго.

Что почти не устаревает — это умение видеть, как всё соединяется. Как данные текут от одного сервиса к другому. Где на стыке двух систем прячется риск. Почему сбой здесь всплывает совсем в другом месте. Это знание не про кнопки конкретного инструмента, а про то, как устроено целое, — и оно переносится с одной технологии на другую, потому что стыки есть всегда, чем бы ты их ни соединял.

ИИ, я думаю, только усилит это. Он всё лучше справляется с локальной задачей внутри одного инструмента: написать скрипт, набросать конфиг, найти ошибку в отдельном куске. Чего он не делает — это не берёт на себя понимание целого: что с чем связано, что сломается, если это изменить, чем на самом деле рискует организация. Чем дешевле становится работа с отдельными частями, тем ценнее тот, кто держит в голове всю картину.

Поэтому я не советую становиться человеком одного инструмента. Изучай инструменты — но вкладывайся в понимание того, как они складываются в живую систему. Специалист по кнопкам конкурирует с автоматизацией. Специалист по стыкам — тот, без кого ни автоматизация, ни новый инструмент сами по себе не работают.

– Serguey Shinder

IT, который говорит «нет», проигрывает тому, кто говорит «как»

Serguey Shinder — Fri, 28 Aug 2026 19:49:38 +0000

Есть два типа IT-отделов. Один по умолчанию говорит «нет». Другой — «а как это сделать безопасно». И со временем первый всегда проигрывает второму, даже если технически он прав чаще.

«Нет» кажется ответственной позицией. Просят что-то рискованное — ты отказываешь, защищая систему. Иногда это действительно правильно. Но если «нет» становится рефлексом, происходит нечто плохое: бизнес перестаёт приходить к тебе. Люди находят обходные пути, поднимают что-то в тени, тащат данные в сторонние сервисы — не потому что они безрассудны, а потому что им нужно делать свою работу, а ты стал стеной, а не дверью. И теперь риск, которого ты пытался избежать, живёт там, где ты его вообще не видишь.

Отдел, который говорит «как», играет иначе. Он тоже видит риск — но вместо того чтобы закрыть дверь, ищет способ провести человека через неё безопасно. «Так делать нельзя, но вот как можно добиться того же, не подставив нас». Тот же уровень защиты, противоположный результат: бизнес идёт к тебе, а не в обход тебя.

Разница не в стандартах. Она в позиции. «Нет» ставит тебя против бизнеса. «Как» ставит тебя рядом с ним, по одну сторону задачи. Первое делает из тебя препятствие, которое учатся обходить. Второе делает из тебя человека, к которому идут первым.

Не будь тем, кто просто охраняет систему, говоря «нельзя». Будь тем, кто помогает бизнесу получить желаемое, не поставив всё под удар. «Нет» защищает систему один раз. «Как» защищает её постоянно — потому что тогда тебя не обходят стороной.

– Serguey Shinder

Схема — это обещание; меняй её осторожно

Serguey Shinder — Fri, 28 Aug 2026 19:44:27 +0000

Схема данных — это обещание. Каждый, кто читает или пишет в твою базу, полагается на то, что данные выглядят так, как договорились. И когда ты меняешь схему неосторожно, ты нарушаешь обещание, которое дал коду, о существовании части которого мог давно забыть.

Я усвоил это, выкатив «безобидное» изменение — переименовать колонку, ужать поле, поменять тип. В моей голове это было мелочью. На деле от этой колонки зависели отчёт, интеграция и старый сервис, о которых я даже не вспомнил. Изменение прошло — и три вещи, никак не связанные с моей задачей, тихо сломались, потому что обещание, на которое они опирались, внезапно перестало действовать.

С тех пор я меняю схему так, будто на неё смотрит кто-то, кого я не вижу, — потому что почти всегда так и есть. Не ломать, а расширять: сначала добавить новое рядом со старым, дать всем перейти, и только потом убрать старое. Не большой прыжок, а несколько маленьких, обратимых шагов. Каждый — так, чтобы старый код продолжал работать, пока не будет готов новый.

Это медленнее, чем одно резкое изменение. Но резкое изменение быстрое ровно до того момента, пока не станет очень медленным — когда придётся среди ночи разбираться, что именно ты сломал и у кого.

База данных редко принадлежит одному сервису. Это общий контракт, на который тихо опираются многие. Обращайся с изменениями схемы как с изменением публичного обещания: осторожно, обратимо, ступенчато. Данные почти всегда переживают код, который их создал, — а значит, и обещания о них надо держать дольше, чем кажется.

– Serguey Shinder

Автоматизируй процесс, а не хаос

Serguey Shinder — Fri, 28 Aug 2026 19:39:15 +0000

Прежде чем автоматизировать что-либо, стоит задать неудобный вопрос: а сам процесс — хороший? Потому что автоматизация не чинит плохой процесс. Она просто заставляет его ломаться быстрее и в большем масштабе.

Это ошибка, которую я видел не раз. Есть запутанный, кривой процесс, полный лишних шагов и странных обходных путей. Он всех раздражает, и кто-то решает: давайте это автоматизируем. Но если взять беспорядок и завернуть его в скрипт, получится автоматизированный беспорядок — те же лишние шаги, те же странности, только теперь они выполняются молча, без единого человека, способного заметить, что всё это не имеет смысла.

Автоматизация усиливает то, что автоматизирует. Хороший процесс она делает быстрым и надёжным. Плохой — быстрым, надёжным и плохим. Ошибка, которую человек раз в неделю ловил вручную, теперь повторяется сто раз в день, потому что скрипт делает ровно то, что ему сказали, включая глупости.

Поэтому первый шаг автоматизации — не писать код. Это упростить сам процесс. Убрать лишние шаги. Спросить, зачем вообще делается каждый из них. Часто оказывается, что половина действий существует по историческим причинам, которых давно нет, и после чистки автоматизировать остаётся почти нечего — и это хороший исход.

Сначала наведи порядок, потом автоматизируй. Автоматизировать хаос — значит просто разогнать его. А автоматизировать понятный, чистый процесс — значит по-настоящему освободить время и убрать целый класс ошибок. Порядок сначала. Скорость потом.

– Serguey Shinder

Проектируй под отказ, а не надейся, что его не будет

Serguey Shinder — Fri, 28 Aug 2026 19:34:05 +0000

В облаке есть соблазн поверить, что оно не падает. Оно падает. И система, построенная на надежде, что этого не случится, — это система, которая однажды подведёт именно тебя.

Провайдер даёт впечатляющую надёжность, и легко принять её за гарантию. Но регионы отключаются, сервисы деградируют, сеть между узлами иногда просто исчезает на несколько секунд. Это не редкие катастрофы — это нормальный режим работы больших систем. Вопрос не в том, случится ли отказ, а в том, что произойдёт с тобой, когда он случится.

Разница между командой, которая переживает сбой облака, и той, для которой он становится своим сбоем, — в одном допущении. Первая проектирует так, будто любая часть может отказать в любой момент. Повтор запроса, если он не прошёл. Запас, если один узел выпал. Понимание, что произойдёт, если недоступен целый регион. Вторая молча предполагает, что всё всегда на месте, — и в день, когда это не так, оказывается без плана.

Проектировать под отказ не значит быть параноиком. Это значит быть честным: раз отказ неизбежен, встреть его решением, а не надеждой. Пусть падение одной части будет неприятностью, а не катастрофой.

Надёжность провайдера — это фундамент, а не страховка, которой можно заменить собственную инженерию. Ты всё равно отвечаешь за то, как твоя система ведёт себя в худший день. Спроси заранее: что сломается, если это упадёт? И построй так, чтобы ответ был «немного», а не «всё».

– Serguey Shinder