Сколько у Вас DBA и сколько у Вас баз данных?

Аналитическая компания Forrester проводит много разных исследований. Одно из исследований было такое: Сколько баз данных (инстансов в понятии Oracle) в среднем администрит один DBA.

Forrester несколько раз публиковал график, который говорит нам, что например в 2000 году на одного DBA в среднем приходилось 15 баз данных (инстансов в понятии Oracle), в 2007 24 баз данных, и в 2010 году 40 баз данных на одного DBA. За всем этим нет какой-то большой науки. Они просто профессионально проводят опросы и публикуют статистику.

Я спросил один очень крупный американский инвестиционный банк сколько у них DBA и сколько у них баз данных (объяснив им при этом, что под базой данных я подразумеваю instance в понятиях Oracle). И большой IT-начальник того банка сказал мне, что у них глобально в мире около 5000 баз данных (Oracle, DB2, SQL Server, Sybase и т.д.) и 346 DBA, которые администрят эти 5000 баз данных. Я тупо разделил одно число на другое, получилось 15 баз данных на одного DBA. И тогда я наложил это число на график Forrester и сказал тому начальнику, что их компания живет в состоянии, в котором большинство компаний были 10 лет назад (по данным Forrester). И начальник меня понял, так как раньше он работал в другом инвестиционном банке, где это число получалось намного выше. Теперь банк разворачивает программу повышения уровня автоматизации работы DBA, чтобы достичь метрику 40 баз на DBA.

Мне просто интересно что мы имеем в России, и я думаю всем будет очень интересно, если читатели этого блога на правах анонимности оставят комментарии к этому посту, написав сколько у Вас DBA и сколько у Вас баз данных.

Вопрос в общем-то очень простой :^)

Пояснения:

  • Всех баз данных, не только Oracle. (Под базой данных мы понимаем instance в понятиях Oracle. Я знаю, что в SQL Server, например, базой данных называется что-то похожее на schema в Oracle).
  • Я знаю что в маленьких организациях метрика будет меньше, чем в больших организациях, поэтому если можно опишите также размер организации любыми доступными Вам словами.
  • Пожалуйста, постарайтесь не писать в комментариях к этому посту ничего кроме запрошенной информации. Подискутировать можно в других постах -- их здесь навалом.
UPDATE: Кстати, у аналитика из Forrester, который занимается этим исследованием есть блог, в котором он пишет про собираемую им метрику более подробно.

UPDATE 2: Черт, ну любит у нас народ пообсуждать. Иногда цифры намного и интереснее чем рассуждения "так ли мы живем" и "к тому ли мы стремимися". Всем будет интересно. Хотя бы просто понять порядки цифр. Религиозные приверженцы MS SQL могут прислать данные "в понятиях MS SQL" но тогда пожалуйста укажите еще сколько у Вас физических серверов :^)

13 комментариев:

  1. Анонимный3/5/11 10:12 PM

    30/1
    10/1

    и (не смотря на просьбу) все таки очень хочется подискутировать на тему адекватности этой метрики и сомнительности того что нужно стремиться этот показатель "улучшать" в любую сторону в конкретной организации
    в разных базах используется разный набор фич БД, разная по сложности (просто сложности и сложности поддержки) логика, разные по суровости процедуры чейндж менеджмента, разная вовлеченность ДБА в системное администрирование и разработку
    и еще много параметров от которых зависит загрузка ДБА
    так что говорить что если у вас в конторе 3 ДБА на 1 базку, значит вы в каменном веке, улучшайте свои процессы/автоматизируйте процедуры - это ведь неправильно

    ОтветитьУдалить
  2. Анонимный3/5/11 10:49 PM

    Спасибо за первый комментарий. Вы соврешенно правы. Жизнь намного сложнее чем текст поста. Метрика очень спорная и напоминает "среднюю темрературу по больнице".

    Применять ее имеет смысл только для заказчиков из похожих индустрий и похожего размера. Например, банковский сектор является достаточно развитой (mature) и IT-продвинутой индустрией. Банки более склоняются покупать готовые решения, чем разрабатывать софт самостоятельно. Поэтому IT-ландшафт банков достаточно похож (если банки одной "весовой категории"), поэтому в этом конкретном случае можно попытаться по крайней мере сравнить банки друг с другом по этой метрике и если метрика отличается "на порядок", то наверное что-то не так...

    ОтветитьУдалить
  3. Анонимный4/5/11 9:43 AM

    Организация маленькая, поэтому 6:1

    ОтветитьУдалить
  4. Анонимный4/5/11 10:53 AM

    90/1
    Гос
    Согласен с предыдущим анонимом, база может быть одна, но при этом не давать отдыха.

    ОтветитьУдалить
  5. Анонимный4/5/11 11:26 AM

    Промышленная БД - 2 на Oracle, 1 на MySQL для redmine, 1 на MSSQL для налоговой отчетности.
    БД для разработчиков - 2 на Oracle.
    Т.е. 6 баз.
    DBA как таковых вообще нет. Исполняющих обязанности DBA параллельно с основной работой - 2 человека.

    Промышленное предприятие.
    Более 10000 сотрудников.

    ОтветитьУдалить
  6. Анонимный4/5/11 12:30 PM

    Неправильно считать MSSQL instance как базу. У меня на одном экземпляре сидят по несколько баз от нескольких известных вендоров да еще для нескольких юрлиц, не считая своих внутренних разработок. Всего около 60 шт. И везде свои собственные политики безопасности, свои настройки бэкапа и standby.
    Вы же не будете утверждать, что настроить 60 standby по времени то же самое, что для 1 базы? Или переподнятие на тестовом сервере 60-ти баз так же просто, как и 1-ой?
    И распределять дисковое пространство для 1 экземпляра MSSQL под файлы данных, бэкапы, логи для всех 60-ти разных баз с разними моделями поведения и роста -- это не то же самое, что для одного экземпляра Oracle! Уверяю вас, Сергей, если бы вы ближе знали MSSQL, то не стали бы равнять 60=1. В крайнем случае, вводите коэффициент для MSSQL баз, например, 0.25 и тогда мой один экземпляр MSSQL = 60*0.25=15 экземпляров Oracle
    Wolfon

    ОтветитьУдалить
  7. Анонимный4/5/11 12:44 PM

    >> Неправильно считать MSSQL instance как базу.

    Положа руку на сердце, я вообще не считаю MS SQL за базу :^) Шютка, шютка, шютка. ...А тех кто это администриует за DBA. :^) Шютка, шютка, шютка! Ради Бога простите меня. Юмор такой. Шютка.

    Просто Forrester придерживается именно такой метрики. Наверное потому, что человек, который в Forrester этим занимается раньше был продвинутам DBA по Oracle.

    Если у меня была бы статистика в другой метрике, то мы бы смотрели по той метрике. У Вас есть доступ к статистике в другой метрике?

    В банке про который я писал 16000 баз данный если мы замерим "в понятиях MS SQL" и тогдла получается 46 DBA на базу. Но нет статистики, на которое это можно было бы наложить и замерить. Еще мне повезло тем, что CIO по автоматизации работал раньше в другом аналогичном банке и он понимал, что там, откуда он пришел DBA было меньше, а баз больше, поэтому он не начал вступать со мной в глюбокую дискуссию. Он просто согласился что проблемма эффективнеости существует и надо копать дальше.

    Мне также не надо объяснять что базы данных размером 300TB администрить будет посложнее чем базы данных размером 300MB. Я все это понимаю.

    ОтветитьУдалить
  8. Анонимный4/5/11 12:55 PM

    >> Положа руку на сердце, я вообще не считаю MS SQL за базу
    Я тоже не считаю :))
    Хорошо, я понял вашу логику.
    Ну, придерживаясь таких метрик - 18 экземпляров на 1 DBA. Банк, 250 сотрудников.
    Wolfon

    ОтветитьУдалить
  9. Анонимный4/5/11 4:58 PM

    18 баз 2 DBA
    Это без тестовых

    ОтветитьУдалить
  10. В продакшене 26, а тестовые кто ж считает :) Скажем, сильно за 50.
    На двоих. Хотя там и одному работы на полное время нет, но иногда надо ходить в отпуск, болеть и т.д. Да и не робот ДБА, чтобы нон-стоп вантузом орудовать.

    ОтветитьУдалить
  11. 5 человек
    Постоянно мониторим 5 инстансов
    около 70 крупных БД
    около 600 мелких.
    Организация - крупный ретэйлер

    ОтветитьУдалить
  12. Анонимный6/5/11 5:57 PM

    160 баз данных от 3 крупных заказчиков, большинство в кластерной конфигурации. 2 ДБА.
    Организация - сервисное обслуживание (Management Service Provider)

    ОтветитьУдалить
  13. Анонимный12/5/12 6:31 PM

    2- Oracle
    4- MSSQL(2 физ.сервера)
    1 dba
    400 сотрудников
    страхование

    ОтветитьУдалить