> базу можно слить и через комп менеджера случайно
в нашем случае маловероятно

ну я так понимаю у всех разные размеры компаний

в моем случае 10 человек

безопасник определяет векторы атак - он распишет там табличку и покажет и после этого доступ разработчикам там покажется каплей в море

любая проблема так или иначе решаема, достаточно начать думать над ее решением

она не решаема только если тот кто ее решает - идиот

в медицинском понимании этого слова

это в каком фантастическом фильме? большую часть безопасников которых я видел волнует только наличие секретнета и касперского, и чтобы все порты были закрыты

вылечите артроз и рак пожжелудочной))))

Доступ к скриптам можно предоставить обученной девочке через веб-интерфейс (админку). Тогда она не может сделать ничего другого, кроме того, что делают скрипты.

доступ к проду можно настроить так чтобы была роль которая может запускать но не может менять то что запускает и не видеть секреты (ключи / пароли)
знаю что в дженкинсе есть роль такая (можно запускать но нельзя настраивать сборки)
тогда если нужно чтото определенное то тот у кого доступы на конфигурацию дженкинса может добавить новую сборку для отдельной задачи

если же дать доступ на чтение в пхпАдмин то да можно тогда всю базу так скачать

нет и не должны вообще никогда. доступ туда у dba, возможно у тех/тим лида/лидов. как бекапы: одни не делают, другие уже делают.

+++

на одном из проектов мы поначалу не имели доступа вообще ни к чему из боевого окружения. не только БД (даже ip не знали, его при деплое подставляли нужный, писал деплой сисадмин заказчика), но и к веб-морде проекта.

В итоге было очень весело обсуждать возникающие баги, регулярно запрашивая скриншоты ошибок и просить сисадминов в БД запросы поотправлять. Через пару недель тык-пык-мыкания они сами выдали все доступы под честное слово (собственно, NDA в самом начале подписали)

Хороший код, хорошая система логирования, хорошие тесты на код :)

Сразу видно, что всё это есть :)

обычно проблема не в коде, а в данных. не имея боевых данных, всего не предусмотришь

к логам, понятное дело, мы тоже доступа не имели

Я буду изредка публиковать выдержки из диалогов закрытого техдирского клуба.

ЛОГИ
Топик-стартер: поделитесь, кто чем логи доставляет? Суть задачи, есть несколько десятков датацентров разбросанных по всему миру, там работает куча сервисов которые активно генерят логи в невероятном объеме, хочется все эти логи собрать в одном месте для удобного поиска и анализа. Суммарный рейт логов примерно 450K в секунду. Пока у меня вырисовывается схема Rsyslog -> Kafka -> Clickhouse.
Не elastic, потому, что логов дохрена, Clickhouse дает сжатие почти в 10 раз, elastic наоборот увеличивает хранимый объем раза в полтора. Диски они тоже денег стоят :). К kafka вообще вопросов нет.
Главное слабое звено Rsyslog пока, devops-ы постоянно жалуются на него, то ограничение на преобразование формата, то на количество коннекций, то на размер сообщения. Но вроде все остальное, судя по обзорам сильно хуже, Logstash ресурсы жрет как не в себя, fluentd это вроде вообще руби и про многопоточность можно забыть и т.п. Вообщем что хочется, вход: syslog, stdin, файл. Внутри буффер (датацентры иногда отваливаются) и параллельное сохранение в файлы (конвертация формата, хорошо но не критично). На выходе kafka.
Ещё раз подчеркну, что логи пишутся из разных датацетров, а в датацентрах куча машин и мой главный вопрос про их доставку. И да, компрессия при доставке нужна.

1 Сжатие
Владелец и технический руководитель своего проекта: сlickhouse прекрасен, чего уж тут. Насчет кафки у меня тоже есть вопрос. Вы каким-то сислогом сливаете в кафку и оттуда в кликхаус? Почему не лить сразу в кликхаус каким-то сислогом?
Топик-стартер: сразу лить не получается так как нормального сжатия не получается. Пробовали доставлять RELP-ом и жать SSH тунелем но уперлись в производительнось :(

2 Доставка
2.1 hadoop
Технический директор фото-сервиса: ради такой задачи придумали hadoop. Хадуп без обвеса и есть система поиска по логам. Ты просто в него кладешь файлы логов, и все. Его иммено ради этого и написал амазон.
Co-founder стартапа:
·  Например, вот так: https://www.facebook.com/notes/facebook-engineering/looking-at-the-code-behind-our-three-uses-of-apache-hadoop/468211193919/
·  Вот описание: http://hadooptutorial.info/log-analysis-hadoop/

2.2 graylog
Топик-стартер: насколько мне известно, для хранилища graylog использует elastic со всеми вытекающими, описанными выше :(

2.3 kafka
Топик-стартер: По поводу кафки, на тестах она единственная показывает себя идеально. Она не требовательна к ресурсам, ведет себя крайне предсказуемо и идеально масштабируется
И у кафки хороший набор компрессий которые здорово жмут поток. Перед ней много что пробовали, включая RELP через SSH тунель Ж)
Специалист по запуску сложных финтех стартапов: как из kafka в CH планируешь забирать? Реализация kafka-storage не очень, лучше свой загрузчик написать (благо там работы не много).

Продожение следует...

прекрасный формат выдержек
можно публиковать книжкой подборки раз в месяц