На реальном проекте обучал студентов рисовать отчеты для OeBS на XML Publisher'е.

Через пару месяцев, от заказчика был резонный вопрос "почему высококвалифицированные специалисты консалтера (со ставкой 500$ в день), отчеты делают значительно (в 2-а раза) медленнее, чем вчерашние студенты за совершенно другую зарплату"

Тот случай, когда термин овер квалифаев замечательно характеризует работу

В принципе, требуется тот же био-робот, взял ТЗ, скопи-пастил в комментарии во view, для каждого поля в отчете, через интерфейс OeBS посмотрел источник данных (запрос), скопипастил, написал LEFT OUTER JOIN между табличками.

Код SQL конечно студенты порождали специфический.... Но кого это волнует при SMP-сервере от IBM за полляма долларов? Разумеется когда в запросе оказывалось что табличка раз десять сама с собой соединяется LEFT OUTER JOIN - оно переставало работать. Тогда обращались с вопросом, где ошибка и как исправить )))

Но при всем при этом, я 100% уверен, что данные студенты ни одного отчета, способного "повесить сервер" не написали. А даже думаю, что отчетов работающих больше пары секунд у них так же не было.

Наблюдал картину на другом проекте, когда мега аналитики, создавали мега-ТЗ, который воплощали достаточно квалифицированные программисты и мега админы бегали вокруг продакшен сервера (наверное даже еще более дорогого) и пытались быстро эти отчеты килят, что бы сервер не лег. А что еще может получится, если одного взгляда на ТЗ достаточно, что бы посочувствовать программисту, который будет пытаться это воплотить на PL/SQL )))

В свое время для КАМИС 2000 делал FAQ по обнаружению ошибок: если система не запускается - смотри сюда, код ошибки такой-то - запусти эту программу, код ошибки такой-то - измени в конфиге эту циферку на другую. Аналогично инструкции для стиральной машине.

Системному администратору нафиг не нужно понимать, что какие циферки значат и почему в системе именно так. Он должен действовать по инструкции. Если этого в инструкции нет - обратись в саппорт или вызови ночью на работу программиста ответственного за этот модуль.

Я бы даже сказал, первое требование к системному администратору - ничего НЕ делать.

IMHO & AFAIK
Поведение администратора "от бога":

звонок в саппорт со словами, "у нас Windows полетел, можно ли восстановить БД". После первых слов покрылся потом ))) Но на следующий вопрос, есть ли у bасkup'ы по инструкции, выяснилось, что у человека 5 (ПЯТЬ) разных backup'ов. Начиная от образа диска Acronis'ом и кончая дампом сделанному по инструкции прикладной системы + копия диска уже после сбоя

Первые его действия при сбое - позвонить в саппорт, проинформировать, что система упала и спросить разрешение восстановить системный раздел из Acronis'а. Следующий звонок был через 15 мин, "спасибо, все заработало".

Был контр-пример:

Когда относительно КВАЛИФИЦИРОВАННЫЕ люди, умудрились сломать сервер при ПЛАНОВОМ выключение питания (даже разработчик софта был об этом проинформировать за 2-е недели до выключения)

Когда диски полетели, выяснилось, что одного из backup'ов у них нет, т.к. софт ЯКОБЫ "не работал и выдавал ошибку Нет места на диске, а на диске было еще 2 Gb". Хотя вторая строчка в инструкции (первая - заголовок) была примерно следующая "в связи с особенностью Windows, требуется свободное место для временных файлов в 3-4 раза большее, чем размер записываемого носителя (12 Gb для DVD). В случае если место не достаточно, для предотвращения сбоев система не запускается и выдает ошибку....". Б....дь. Софт не работает!

И это были КВАЛИФИЦИРОВАННЫЕ люди. По технической знаниям, на 2-3 месте в их городе.

Директору заказчика, кроме мата в адрес его сотрудников, пришлось заключать дополнительный договор на работы по сборке БД из отдельных уцелевших архивов. Разработчику пара недель дебильной и мало интересной работы.

Была практически анекдотическая ситуация, когда Oracle упал. Относительно технически грамотные люди, решили залезть в компьютер выполняющий роль сервера, жесткий диск у них не вынимался и они помогли ему зубилом (!). Oracle этого не перенес и упал. Бекапов у них не было (или были на том же диске). Около полгода работы коллектива в 5-10 человек были утеряны полностью.

НО ЭТО СИСТЕМНОЕ АДМИНИСТРИРОВАНИЕ

Администрирование прикладной системы - фактически аналогично. Прочти документацию, выполни все по документации, свяжись с саппортом.

В том же самом КАМИС 2000, функции администратора прикладной системы, выполняли вообще девочки-музейные сотрудницы. С уровнем технических знаний: умение пользоваться электронной почтой, разархивировать файлы из zip'а, запустить на Windows командную строчку и запустить там команды и скопипастить ответ в письмо.

Отсутствие технических знаний, как-то не мешало им даже ставить и настраивать Oracle ))), диагностировать ошибки сети и так далее. Конечно инструкции со скриншотами и указанием, какие галочки нужно нажать.

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

Вроде, даже, иногда они и шаблоны отчетов правили. На уровне изменить шрифт, изменить фразу и так далее.

Вот у них проблем, что бы сервер полетел в результате использования зубила или место на диске кончилось - как-то не было от слова СОВСЕМ.

В общем, цитируя Эвклизиаста "от многих знаний, много печали".

Разница между SaaS или клиент-сервер как ни парадоксально не такая уж и большая. В той же системе КАМИС 2000, запуск происходил так:
1. Запустилась система. Все параметры в иконке: путь к Forms Runtime, строка соединения с БД и схема в БД конкретного заказчика
2. Система сравнила файлы на диске клиента с табличкой S_FILES. Если отличается - обновилась. Система перезапустилась с корректной версией файлов
3. Работаем

Единственное что отличало заказчиков с точки зрения софта (в офисе) - просто их код - имя схемы в БД. В общем-то, так же ))).

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

Как пример реальной потребности.

Один из заказчиков обнаружил ошибку в ядре системы. Для него это критично. Вносить изменения в ядро - долго (внесли изменение, оттестировать, смержить в release). Нам требуется придумать для заказчика work around

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

Тогда workaround/заплатку можно выпустить на уровне конфигурации для конкретного заказчика, а bug fix / path для остальных через некоторое время, в очередном релизе.

Опять таки, желательно, что бы прикладной язык и язык ядра были максимально одинаковые.

СУБД или есть или ее нет. При чем тут микросервисы вообще не понятно.

1) Первый сценарий

Пусть есть СУБД Oracle Personal Edition работающая на домашнем компе. Есть две таблицы и FK между ними. Все понятно

Пусть есть СУБД Oracle EE в RAC конфигурации где ноды расположены на разных континентах. Все то же самое. Есть таблица и есть FK.

На каком континенте расположен конкретный блок данных СУБД - задача СУБД, кластерной файловой системы и так далее. Если у нас экзадата, то select может выполняться вообще чуть ли не на уровне винчестера. Но нам пофиг! Т.к. это задача СУБД.

Для пользователя, прикладного программиста, программиста PL/SQL и так далее - ничего не меняется.

2) Второй сценарий

Есть приложение созданное на Oracle с двумя табличками и FK между ними

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

Вот у меня ровно такая аналогия рождается. Только с микросервисами это никак не связано.