Не всякий девелопер долетит до PROD, что конечно, правильно, и более того, в ряде случаев регулируется законами разных стран (персональные данные, кредитные карты итд). Однако для эффективного функционирования важны не только восходящие потоки (деплой DEV → QA → PROD), но и нисходящие, существующие в виде предоставления девелоперам очищенных баз для тестирования, метрик с PROD, логов, сообщений об ошибках, и, в худшем случае (проблема существует и воспроизводится только на PROD) доступе разработчиков на PROD.
Лирическое отступление. С детства мне в память врезались (видимо из журнала «Наука и Жизнь») шкалы землетрясений и ветра. Интересно двигаться по баллам ветра плавно переходя от «ветер едва колышет листья» до «ветер с корнем вырывает деревья». Давайте и мы составим такую шкалу для уровней сложности попадания на production (с акцентом на базы данных) — с примерами и рассказами из жизни.
Я пойду в противоположном направлении, от максимально закрытого PROD к максимально открытому.
10. Доступа к PROD нет вообще
Кроме супер админов, которые управляют серверами. Но аппликации для этих людей, как правило, черный ящик, и максимум, что они могут сделать — это прислать по почте текст ошибки из какого нибудь лога (или support пришлет screenshot) — и крутись, как знаешь.
9. Только логи и метрики
Kibana, Splunk, графики в Grafana и Zabbix, и все. Часто считается, что этого достаточно. Не только для девелоперов, но даже для людей, ответственных за анализ производительности систем. Для Windows числа для графиков берутся из PerfMon.
Я не знаю, у кого в голове родилась идея, что этого достаточно и по числам PerfMon можно построить систему алертов и судить о произодительности систем. Начнем с того, что все интересные метрики MS SQL server (я буду говорить чаще всего о нем, так как я DBA) вычисляются с помощью сложных запросов.
Например, вы можете проверять метрику PerfMon для MSSQL server “Total locks”, но во‑первых, блокировки иногда — это нормально (например, MSRS использует блокировку по WriteLockSession для синхронизации. Во вторых, в высоко нагруженных системах бывают короткие блокировки 5–7–10 процессов, которые рассасываются за секунды.
Любой DBA напишет кверь где упомянет, например, where DbName<>'ReportServer', а также waittime>15000 (чтобы не беспокоиться о совсем коротких блокировках).
Впрочем, если вы считаете, что одно число вам что-то говорит, то я предлагаю вам ввести себе метрику: «Число ваших родственников, с которыми случилось что‑то серьезное». Поставьте алерт на >0. Пусть вам позвонят и скажут, что метрика из 0 стала 1, но не будут отвечать ни на один вопрос: ДТП? Больница? Что-то еще? Тот, кто позвонил, вам не скажет - сюрприз. Вы должны доехать до дома законнектиться и сами все посмотреть.
Для меня всегда алерт — это число и текст, микро‑рассказ о ситуации. Чтобы, будучи дежурным DBA и увидев этот текст на телефоне вы могли быстро решить — бросать начатую еду или завалился фоновый процесс, который вообще не важен. Вот что даст вам число failed jobs? Детальная информация не важна, если дежурный сидит неотрывно за монитором, и отходя на три минуты пишет: я отошел, я вернулся. (я чуть было не устроился в фирму, где такое считалось нормальным)
Впрочем, даже графики графаны это уже хоть что‑то — мне кажется с психологической точки зрения возможность чувствовать биение сердца PROD мотивирует.
8. Митинг без лапок
В некоторых случаях проблемы просто так не решить. Она существует только на PROD, или только там и воспроизводится, или зависит от конкретных данных. Тогда админы могут создать митинг и пошарить экран.
Девелопер должен смотреть в экран и диктовать, что надо делать. Управления клавиатурой и мышью не передается, потому что у него лапки. На самом деле в этом есть смысл — например, когда нам помогали консультанты от VMware, они сказали что никогда не берут управления мышью и клавиатурой на себя. Поэтому, если систему снесут в ноль, то это будет сделано не их руками.
Но отсутствие управления придает митингу неповторимый колорит. Так, набирайте select * from fnvirtual... там подчеркивание. fn_virtual_file_stats. А вот дальше подчеркиваний нет, уберите. Убираем. Теперь выполним. Направо подвиньте. Нет, слишком. Назад. А вот. Черт, опять пролетели. Чуть назад. В смысле вверх.
Если у вас есть наработанный список скриптов, то можно их продиктовать (да, да, и такое бывает!), или послать (например, по почте), и после томительного ожидания их смогут перетащить на сервер. То же самое в другую сторону, для результатов.
7. Митинг с лапками
Здесь скорость работы очень увеличивается. Правда, комфорт вырастает ненамного. Я, например, интраверт и не люблю работать, когда на меня смотрят. После часа митинга приходишь в себя и понимаешь, как тупил и как бы быстро бы все сделал, если бы не стояли над душой.
Ну и проблемы с передачей кода туда и результатов обратно по‑прежнему напрягают.
6. Временный доступ без copy/paste по тикету
В одном подразделении была система CA PAM, которая давала доступ к серверам только, если был открыт инцидент. Запрограммировали ее хорошо, вот только результаты были довольно неожиданные.
Во‑первых, как только состояние ошибки исправлялось, инцидент автоматически закрывался, и Remote Desktop тоже. Для бедного исполнителя это было очень неожиданно, тем более что он не успевал ни выполнить дополнительные проверки, ни удалить временные объекты и файлы.
Но много хуже было то, что человек в один момент времени мог заниматься только одним инцидентом. Например, когда требовалось сделать бэкап огромной базы, индусы сидели у экрана 12 часов и смотрели на экран, потому что ничего другого делать не могли. Кстати, им приходилось все время дергать мышкой для предотвращения дисконнекта, а программ типа mouse mover они не знали. Впрочем, не думаю, что они очень страдали.
Кроме того, один исполнитель не мог оставить другому возможность продолжить работу. В общем, иногда хорошая автоматизация бывает во вред.
5. Временный доступ с approve
Там, где я долго работал, для важных систем доступ девелоперам давался по аппруву. Но им обычно давалось значительное время (до 3 дней), ну и появлялся copy/paste (впрочем, наличие copy/paste не так жестко привязано к уровням, скорее это коррелирует с уровнем затянутости гаек)
4. Временный доступ с auto-approve
Очень похоже на предыдущий пункт, но тут не нужно ждать человека. Такие системы, скорее, не вахтер, который должен "не пущать", а средство аудита (но оно не должно быть единственным)
3. Постоянный доступ избранным
Речь не о супер-пупер админах, а о тех, кто привлекается со стороны разработки. Скорее всего, это небольшое число избранных людей. При комбинировании с пунктом 5 именно они и дают аппрув.
2. Постоянный доступ избранным, остальным read-only
Здесь под «read‑only» понимается доступ к базе. Read‑only доступ к Windows server через RDP сделать куда сложнее, хотя у меня есть решение, позволяющее предоставлять пользователям результаты любых отчетов, созданных скриптами PowerShell или python, то есть вырваться из жестких рамок того, что можно сделать в Zabbix/Grafana/PowerBI/MSRS. Для демо есть docker image — на самой первой странице.
1. Без ограничений
Ну а почему нет? Если два приятеля в гараже сделали сайт, то оба имеют полные права. Впрочем, такая ситуация сохраняется иногда и при росте стартапа довольно долго. Я в 2000 году в Америке работал в таком. Впрочем, они плохо кончили. Но не из‑за доступа к PROD.
Опрос
Пожалуйста, примите участие в опросе. Вы можете выбрать несколько вариантов (рекомендую выбрать два), например в случаях:
В моей старой фирме так, а сейчас иначе
Или с большинством систем так, а с PCI иначе
Или — а меня так, а у многих больше или меньше доступа.
Очень интересно также послушать, насколько сильно завернуты гайки неудобства (отключение copy/paste, таймаут на завершение сессий, если она не активна, наличие большого количества прыжков (вначале прыгаем на сервер Х, потом оттуда на Y, и уж там запускаем Remote Desktop/ssh), наличие многих доменов без доверия — разные пользователи и пароли, иное) — делитесь в комментариях!
