Типичная ошибка оленя

Проанализировал (проаленизировал, мля) свои браки; 3 законных, 1 граждански1 вообще какие-то боле-менее длительные ( больше 4 месяцев) отношения. Интересных вещей нашел много. Здесь хочу заявить одну.
Всем нам хотелось узнать почему с такой скоростью разваливаются вроде прочные отношения, причем всегда по –одной схеме. По АБФ – у баб прошивки практически одинаковые . Это понятно. Но отсюда следует вывод – у Аленей тоже. Иначе было б какое-то разнообразие. Вернее, у аленя должны быть внедрены и активирована некоторые программы, которая системно приводит к пестецу. Они несут системные ошибки.
Системных ошибок Аленя всего две.
1) – потребность быть нужным всем- ОЖП, Детям, Семье, Трудовому, штоб ему не похмелиться, коллективу, Домашним животным, Стране, Президенту, мировому Капиталу и Мировому же пролетариату. А вот Себе в последнюю очередь.
Здесь есть тонкая грань. Америкосы ее знают. Так вот, они очень хорошо различают слова – Нужный-Полезный и Важный. Поэтому, когда они хотят раскрутить партнера на халяву и ништяки, они говорят – вы очень Важный, это для нас Важно.

Так вот, Алень эту разницу не замечает. Алень считает, что раз Нужный- то. однозначно, Важный. вот куй в рот. Баба считает, что поток ништяков от Аленя – это ее дивидиенды за вложенный пельмень.

Поэтому, перед Аленями сразу рушиться картина мира, когда баба, много лет плотно сидевшая на поток ништяков, спокойно слезает с этой иглы. Так вот, ей это было Нужным, но не Важным. Бабья прошивка эти понятия разделяют. А троян, засевший в Алене, эти понятия смешивает. Причем любая нетупая ОЖП искусно поодерживает это заблуждение в ОМП , подчеркивая его мнимую для нее значимость, чтобы поток ништяков был стабилен. ( в Алене поддерживается шаблон Настоящий Мужыг)

Итак, В семье надо быть Важным. Важность надо демонстрировать. Бабо, как правило, не видит вашу Важность на работе, крайне редко – на стадионе. и эта удаленная Важность Аленя сродна мифической.

2) Бабо хочет быть желанной. Напишу-ка большими буквами и курсивом. БАБО ХОЧЕТ БЫТЬ ЖЕЛАННОЙ.

Когда бабо талдычит свое заклинание “ниудилявнимания” и “янечувствоваласебяженщиной” Это и значит – я не чувствала себя ЖЕЛАННОЙ.

Так вот, Алень думает, что поток ништяков, куча пережитых пендатостей и преодоленных пестецов , любимые спиногрызы и синяк в паспорте – это достаточно, чтобы баба будило его по утрам губами закуй. НЕТ. Второй куйврот – Ей надо чувствовать себя ЖЕЛАННОЙ. Только такое внимание чотазначит и токаприэтом она чувствует себя женщиной.

Тока не спрашивайте меня, что это такое. Я не знаю, я не пидор. Могу предположить. От скромных “я чувствую, что меня хотят выипать” – “я чувствую, что хотят выипать лично меня” – до кокетливых: “Я чувствую, что он хочет меня выипать” — я чувствую, что он хотят выипать только меня” – и обнаглевших “Я чувствую, что все хотят меня выипать” — я чувствую, что все хотят выипать”только меня’. Но мы тут не ахреневших лядей лечим.

Продолжу

Всем привет. Мне 25 ей 22.

Есть время стать мужиком, ну а теперь по порядку …

Предыстория: познакомила меня с ней её лучшая подруга.

Хорошее начало, сам что ни как не можешь с ОЖП познакомиться?

Начал ухаживать, вела себя очень робко, было пару встреч.

Ну конечно, все они изначально робкие, автор, читать срочно про проверки со стороны ОЖП

Общение было в основном по телефону. Секса небыло. Сказал что если она не хочет видится мне это не нужно. Не восприняла в серьёз. Сказал досвидания и пропал на 4 месяца.

Ну ну, СЕКСа не было, какие отношения могут быть? Все было нормально, посла так послал.

После четырёх месяцев позвонила сама, попросила забрать с непонятной компании.

Ау, а где же песик,

Оказалась что находилась у той самой подруги. Приехал, пообщался.

А вот и песик, гав-гав … прогиб засчитан.

Потом сама начала общаться. Дальше опять провал. Забил.

ОЖП ждала, что ты завалишь ее и трахнешь, но ты снова развел плутоническую любофф

8 марта так вышло что попал в общую с ней компанию, начала жутко ревновать, я свёл это всё в шутку.

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

Потом сказала что хочет отношений, типа созрела.

А ну да, пока перспективного ничего не нет на горизонте, а пилотка то чешется.

Вроде бы всё не плохо.

Да ладно, все ужасно!

Общались, потом началось то что она постоянно проводила время со своими подругами.

Значимость — Ау, ты где? 

Меня это не устраивало категорически, потому что постоянно на работе и как только появлялось время старался проводить его с ней.

Все работают и что?

Не ухаживал за ней сильно, подарков не дарил.

Типичное мнение оленя.

Постепенно сблизились.

Интереснее уже …

Секс не регулярный но был.

От чего же? Упахивался? Или голова болела, она уставала или как?

Полюбил.

Пельмень на голове.

Сократили с работы, начал гораздо больше времени с ней проводить. Проблема не менялась.

Типичная ошибка Оленя, с чего же меняться проблеме, если сама проблема в тебе, Автор!

О чувствах говорил. Она мне нет.

Ога, оленеводство полным ходом.

Далее начал делать подарки и заваливать цветами.

У-у-у-у-у, как все запущено. Бабки то в кредит на цветы взял?

Она перестала уделять мне внимание вообще.

Ну вот, за чем ей такой олень как ты!

Начались ссоры и постоянные разговоры об отношениях.

Тебе лишь бы языком по трендеть? Мужик сказал — мужик сделал. ОЖП не понимают слов, они понимают действия.

Говорит я на неё давлю и не даю побыть одной.

Конечно, все верно, на фига ты ей, писдоболы ни кому не нужны, а там реальный самец на горизонте, под которого она готова лечь и течет по нему, как ниагарский водопад.

Попросила об отдыхе, подумать, разобраться в себе.

Ага, все как по шаблону, ну а ты …

Не трогал.

конечно же по верил, и тут …

Пошёл к другу и встретил её с подругой.

побежал за ней следить, и там …

Решили посидеть вместе. Опять выяснение отношений и в итоге она сказала что всё кончено.

снова тебя переклинело, аленизм вылез на поверхность и тебе выписывают ДОД.

С утра позвонил, решил поговорить, услышал гневную реакцию, попросила оставить её в покое и что все кончено.

Для тупых еще раз тебе повторили …

Потом позвонила её сестра, узнать как дела, рассказал. Сказала что оставь её на какое то время и время покажет что и как.

А то, потом появляется сестра, подружка, друг, подружка друга, общая знакомая и говорит — Олень, ты в ДОДе, оставь ее или как вариант — Ща, погоди, она там с Васей натрахается, и если что к тебе вернется, а если не вернется прозвучит фраза — либишь, отпусти и так далее, вариантов развития много …

Помогите разобраться с ситуацией, хочу вернуть её.

Но нет, пельмень так глубоко засел, что люблю нимагу!

Никаких вернуть. Читать форум от и до. 

ВВП+Т10Д+ БОЖП в ТИ. 

Развивайся, видно что ты себя не уважал ни капли. 

И сокращение твое с работы не решает, ты можешь иметь за душой всего копейку, но стержень свой терять не обязан.

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

Пока у тебя не будет мужских стальных яиц, ловить тебе там нечего. Бабу в ИГНОР, сам в развитие, Т10Д — обязательно … Да, ты можешь воспользоваться советами форума или поступить

а лучше еще  woman точка RU, там тебе скажут что делать, если ты не веришь форуму.

В марксисткой школе политэкономии считается, что все обмены являются обменами равного на равное.
Но так ли это?

Начнем анализ с Адама Смита.

Рассуждение Адама Смита

«В обществе первобытном и малоразвитом, предшествовавшем накоплению капиталов и обращению земли в частную собственность, соотношение между количествами труда, необходимыми для приобретения разных предметов, было, по-видимому, единственным основанием, которое могло служить руководством для обмена их друг на друга. Так, например, если у охотничьего народа обычно приходится затратить вдвое больше труда для того, чтобы убить бобра, чем на то, чтобы убить оленя, один бобр будет, естественно, обмениваться на двух оленей, или будет иметь стоимость двух оленей.
Вполне естественно, что продукт, изготовляемый обычно в течение двух дней или двух часов труда, будет иметь вдвое большую стоимость, чем продукт, изготовляемый обычно в течение одного дня или одного часа труда
».
(Адам Смит, «Исследование о природе и причинах богатства народов», стр. 29)

Вполне логичное рассуждение, если рассматривать только охотничий народ, и не предполагать у этого народа наличие разделения труда.

Рассуждение Давида Рикардо

Давид Рикардо через 40 лет после издания книги Адама Смита просто повторяет написанный выше абзац в своей книге и даже обвиняет А.Смита в отходе от этого принципа:

«Но Адам Смит, который так правильно определил коренной источник меновой стоимости, оказался непоследовательным. Вместо того чтобы строго держаться принципа, в силу которого стоимости предметов увеличиваются или уменьшаются в зависимости от увеличения или уменьшения затраченного на них труда, он выдвинул еще другую стандартную меру стоимости и говорит о предметах, стоящих больше или меньше, смотря по тому, на большее или меньшее количество таких стандартных мер они обмениваются». (Давид Рикардо, «Начала политической экономии и налогового обложения»)

Рассуждение Карла Маркса

Еще через 40 лет после Давида Рикардо Карл Маркс берет на вооружение ту же теорию и уже на 4-ой странице Капитала делает ее фундаментом своей теории:

«Вместе с полезным характером продукта труда исчезает и полезный характер представленных в нем видов труда, исчезают, следовательно, различные конкретные формы этих видов труда; последние не различаются более между собой, а сводятся все к одинаковому человеческому труду, к абстрактно человеческому труду».
(Маркс К., «Капитал», Т.1, К. Маркс и Ф. Энгельс, Сочинения. Изд.2-е, Т. 23, стр. 46).

Рассуждение Адама Смита о бобрах и оленях Карл Маркс трансформирует в рассуждением о сюртуках:

«Но допустим, что труд, необходимый для производства одного сюртука, возрастает вдвое или падает наполовину. В первом случае один сюртук стоит столько, сколько раньше стоили два сюртука, во втором случае два сюртука стоят столько, сколько раньше стоил один, хотя в обоих случаях услуги, оказываемые сюртуком, остаются неизменными, равно как остается неизменным и качество содержащегося в нем полезного труда. Но количество труда, затраченного на его производство, изменилось».
(Маркс К., «Капитал», Т.1, К. Маркс и Ф. Энгельс, Сочинения. Изд.2-е, Т. 23, с. 54)

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

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

Разделение труда, повышение производительности

До того, как говорить о бобрах и оленях, Адам Смит поясняет о специализации и разделении труда:

«В охотничьем или пастушеском племени один человек выделывает, например, луки и стрелы с большей быстротой и ловкостью, чем кто-либо другой. Он часто выменивает их у своих соплеменников на скот или дичь; в конце концов он видит, что может таким путем получать больше скота и дичи, чем если сам будет заниматься охотой. Соображаясь со своей выгодой, он делает из выделки луков и стрел свое главное занятие и становится таким образом своего рода оружейником. Другой выделяется своим умением строить и покрывать крышей маленькие хижины или шалаши».
(А. Смит, «Исследование о природе и причинах богатства народов», стр. 10).

И на той же странице:

«Различные люди отличаются друг от друга своими естественными способностями гораздо меньше, чем мы предполагаем, и самое различие способностей, которыми отличаются люди в своем зрелом возрасте, во многих случаях является не столько причиной, сколько следствием разделения труда… Но не будь склонности к торгу и обмену, каждому человеку приходилось бы самому добывать для себя все необходимое ему для жизни».
(А. Смит, «Исследование о природе и причинах богатства народов», стр. 10)

Адам Смит, говоря о появлении разделения труда, увязывает ее с повышением производительности труда. Но позднее, говоря о меновых пропорциях, пренебрегает повышении производительности.

За Адамом Смитом позднее то же самое делают сначала Давид Рикардо, потом Карл Маркс.

Мы не будем пренебрегать этим важным моментом и разберем «бобров и оленей» подробно.

Специализация, возрастание производительности труда и меновые пропорции

Равная производительность труда. Специализации нет

Предположим, что в племени у охотничьего народа, где все являются охотниками и все имеют одинаковую производительность труда в охотничьем деле, простому охотнику на добычу одного бобра, скажем, надо 10 дней, а на добычу оленя надо 5 дней (мы пренебрежем тем, что ценность зверя обычно пропорциональна его весу, что счастье охотника – вещь случайная, и будем придерживаться пропорции Адама Смита).

При этом охота на мелких животных (заяц, утка, белка и т.д.) требует одного дня.

Тогда можно принять как очевидную и справедливую, ту пропорцию, что за одного бобра будет даваться два оленя. И что обмен при этом будет равноценным, и не приносящим никакой выгоды обменивающимся. Если только они не обменивают излишки, которые по каким-то причинам ценят ниже. И что один бобер будет стоить десяти уток. А один олень – пяти уток. Уток мы сделаем мерой ценности.

Теперь предположим, что в обществе появляется разделение труда и связанное с ним изменение производительности труда.

Разная производительность труда. Специализация есть

Мы делаем то предположение, которое не сделали ни А.Смит, ни Д.Рикардо, ни К.Маркс.

Предположим, что в племени появились охотники, которые за счет своего умения и опыта достигли особой умелости. Одни – в добывании бобров: они стали добывать бобров в пять раз быстрее – не за 10, а за 2 дня.

Другие – добились особого умения в добывании оленей. И они стали добывать оленей не за 5 дней, а за 1 день.

Остальные охотники отошли от охоты на бобров и оленей, но стали охотиться на остальную дичь, добывая в день, как и раньше, – по одному зайцу, белке или утке в день.

Общество стало тем, чем оно является с момента появления разделения труда.

Пропорция в трудоемкости добывания бобров и оленей не изменилась – трудоемкость бобра осталась в два раза больше трудоемкости оленя. Этот момент мы оставляем, чтобы было понятно, что упустили названные нами авторы.

На первый взгляд можно забыть о появлении разделения труда и пойти по пути «классиков»:

— меновая пропорция бобров и оленей не изменилась,

— обмены не становятся взаимовыгодными,

— прибыль при обмене не может появляться.

Но мы такой ошибки делать не будем, а разберем экономическую суть обмена детально.

Детальный анализ обмена

Поясню, почему ростом производительности пренебрегать нельзя.

Высокая производительность отдельных охотников (охотников на бобров и оленей) – это их личное достижение, которое достигнуто их стараниями. Племя, которое не умеет добывать бобров и оленей не имеет права наказывать их за навыки и не будет этого делать. Наоборот, их навыки будут заслуженно вознаграждены.

Приходя с охоты, каждый охотник на бобра получает из общей добычи племени 10 уток. А охотник на оленей, приносящий в племя оленя, будет получать за него 5 уток.

Выгода умелых охотников от обмена по старым пропорциям

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

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

Эти охотники оказываются в выгоде от обмена. Они могут позволить себе как увеличение объемов добычи, так и некоторое снижение цены на свою добычу.

Изменение цен с ростом производительности

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

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

Теперь за одного бобра они просят не 10 уток, а только 5. И точно так же охотники на оленей просят за одного оленя – 2,5 утки, а не 5, как ранее.

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

Посмотрим на ту же ситуацию в случае уменьшения цен сделок.

В чем будет заключаться взаимовыгодность сделок?

Сделки с точки зрения охотника на бобра

Продавая бобра за утку (обменивая бобра на уток), продавец бобра получает 5 уток.

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

Его расход – два дня. Его результат — 5 уток. Выгода – 3 утки.

Обменивая бобра на двух оленей, – он совершает не равную, как кажется на первый взгляд, а выгодную сделку. Он отдает результат своей двухдневной охоты, а получает взамен товар, эквивалентный пяти уткам. Чтобы их убить, ему надо потратить 5 дней. Его выгода – 3 утки.

Сделки с точки зрения охотника на оленей

Продавая оленя (обменивая оленя на уток), продавец оленя получает 2,5 утки.

Потратив 1 день на охоту, он получает в обмен результат 2,5 дней охоты других охотников, или 2,5 дней собственной охоты на уток.

Его расход – один день. Его результат – 2,5 утки. Выгода – 1,5 утки.

Обменивая двух оленей на одного бобра, он совершает не равную, а выгодную сделку, отдавая результаты своей двухдневной охоты, получая взамен товар, для получения которого ему надо убить и отдать 5 уток. Т.е. потратить 5 дней. Его выгода – 3 утки.

Сделка с точки зрения обычного охотника

Обычный охотник, покупая бобра (обменивая пять уток на одного бобра), за объем пятидневной охоты получает товар, на добычу которого самостоятельно ему бы пришлось потратить 10 дней.
Его расход по сделке – 5 уток (5 дней охоты). Его результат по сделке – бобер, на которого ему надо было бы потратить 10 дней. Его выгода – 5 дней охоты.

Покупая оленя (обменивая 2,5 утки на одного оленя), обычный охотник получает в результате добычу, на которую он потратил бы 5 дней. Его результат по сделке – олень, на которого ему надо было бы потратить 5 дней.

Его расход по сделке – 2,5 утки (2,5 дня охоты). Его результат по сделке – олень, на которого ему надо было бы потратить 5 дней. Его выгода – 2,5 дня охоты.

Выгода от сделок для различных категорий общества

С появлением разделения труда и с началом процесса увеличения производительности труда сделки становятся не эквивалентными и равными, а взаимовыгодными.

Это ключевой момент.

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

Со стороны окружающих сделки только кажутся эквивалентными и не взаимовыгодными.

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

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

Покупатель товара (в нашем случае покупатели бобров и оленей) в результате разделения труда и роста производительности труда, вскоре получают экономию времени: теперь им не надо охотиться 10 дней на бобра или 5 дней на оленя, достаточно поохотиться 5 дней на уток.

Или, что одно и то же, они получают экономию средств. Вместо затраты 10 уток на бобра и 5 уток на оленя достаточно потратить вдвое меньше.

Высвободившееся время они могут использовать для семьи, для своих целей.

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

Мы видим естественный процесс в прогрессивном развитии общества: первым от роста производительности труда выигрывает тот, кто эту производительность организовал.

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

И в конечном итоге в выигрыше от снижения общих цен оказывается все общество.

К чему приводит специализация и рост производительности труда

Специализация и рост производительности труда приводят одновременно к следующим результатам:

1. Себестоимость товаров начинает падать.

2. Цены на товары начинают снижаться.

3. Ценность товара, производимого за одну единицу времени у различных производителей, становится различной.

4. У каждого товара появляется не одна, а несколько стоимостей (времени необходимого для изготовления).

5. Сделки обмена и купли-продажи перестают быть равными и эквивалентными для участников сделки, а становятся взаимовыгодными. Каждая из сторон получает или прибыль от сделки, или экономию времени.

6. Появляется прибыль производителя, генерируемая ростом производительности труда.

К сожалению, Адам Смит, Давид Рикардо и Карл Маркс упустили из виду четыре последних пункта, что не позволило им создать целостную систему современных экономических отношений.

Так три животных – бобер и два оленя сначала пустили по неверному пути Адама Смита, а потом и его последователей.

Заключение

1. Исключение из анализа ценности товара для покупателя привело к исключению взаимовыгодности сделок купли-продажи из экономических теорий Смита, Рикардо и Маркса.

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

3. Ошибка в анализе обмена, сделанная школой Смита, Рикардо и Маркса не позволяет правильно понять суть обменных операций, роль повышения производительности труда в экономике.

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

5. Игнорирование школой Смита, Рикардо и Маркса взаимовыгодности обменных операций приводит к неверной трактовке обмена и причин образования прибыли.

Александр Фирсов
11.11.2021

Ситуация «Избавим местность от паразитов» (см. предыдущий пост www.stradis.top/myshlenie-rukovoditelya-sistemnoe-myshlenie) — наглядный пример первой типичной ошибки в системном мышлении — неверного определения пространственных границ системы.

Власти не включили в свое рассмотрение важного элемента «Желание жителей иметь больше денег». Включив его, они, возможно бы, стали платить не за хвосты, а за тушки мертвых крыс (тогда пришлось бы больше потратиться на их утилизацию). Другой вариант — увеличить сумму вознаграждения за каждый хвост так, чтобы жителям было бы проще отрубить хвост у убитой крысы, чем ловить живую. А, возможно, стоило бы провести предварительные разъяснительные работы о вреде, который наносят эти грызуны.

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

В бизнесе верное определение пространственных границ системы может провести к появлению прорывных подходов. Например, весь Agile-подход, по сути, родился из включения в систему разработки продукта элемента «Клиент».

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

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

Ну и совсем классика: игнорирование внешних аффективных пространств в попытке разрешить конфликт лишь на рациональной деловой основе без учета не только того, что было сказано, но и как: с какой интонацией, невербаликой.

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

Ситуация «Где орудие убийства?»

В одном из давно прочитанных мной детективных рассказов жена сообщает, что, пока она готовила обед, ее муж оступился, ударился виском и умер.[1]

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

И «тут появился изобретатель», который, объясняет, что жена убила мужа замороженной бараньей ногой, которую успела разморозить, и продолжала готовить на глазах детектива.

Из этой же серии популярные задачки на сообразительность типа: «Под потолком пустой комнаты повесившийся. Под ним лишь лужа воды. Как это может быть самоубийством? — Ему же надо было на что-то встать, чтобы засунуть голову в петлю?!» Ответ: «Он встал на куб льда, который потом растаял.»

В практике руководителя именно эта типична ошибка в системном мышлении приводит к разочарованию в отношениях: «Я ведь ему/им так доверял, так на них рассчитывал… А он/они?!» Ну, что я в этих отношениях отвечаю своим клиентам? — «Все свое доверие вы высказали на предсказуемости партнера/сотрудника. А предсказуемость в вашей голове появилась лишь из-за того, что вы отказывались рассматривать другие возможные варианты поведения человека. Что ж, давайте укреплять системное мышление, чтобы больше так не обжигаться!»

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

Четвертая типичная ошибка в системном мышлении — непонимание функции системы. — Какие именно продукты с какими приоритетами она должна производить для того, чтобы получать из внешней среды поддержку. Это стандартная ошибка руководителей сервисных подразделений (HR, IT, бухгалтерии, юристов…). Которые считают, что им достаточно давать экспертные заключения и соблюдать определенные требования и нормы в своей профессиональной области, когда на самом деле бизнес ждет от них реального партнерства в достижении бизнес-результатов.

Пятая типичная ошибка в системном мышлении — игнорирование изменчивости системы, особенно вследствие приспособления к изменениям, вызовам из внешней среды.

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

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

Много бизнесов прогорает на сочетании шестой и седьмой ошибок, когда глава компании требует немедленных улучшений за счет внедрения каких-то изменений, а не получив, немедленного отклика, сворачивает начатые изменения и начинает новые. Тогда отложенный эффект от первых изменений принимается за эффект от вторых, и глава компании вообще перестает понимать, что происходит с бизнесом.

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

Ситуация «Что будет стоить это изменить?»

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

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

Вопрос был принципиальным, так как в первом случае для решения проблемы было бы достаточно провести обучение Классическому Ситуационному руководству, а во втором потребовались бы более серьезные системные меры.

Ясность наступила после ответа на вопрос: «Если к нам в команду придет управленец, умеющий ясно ставить задачи, то что из двух с большей вероятностью произойдет? — Большинство остальных руководителей:

1) заинтересуется Классическим Ситуационным руководством и, как минимум, задумается о том, а не попробовать ли его в своей практике, или

2) искренне удивится его непонятному способу постановке задач, и через какое-то время он и сам начнет ставить сотрудникам задачи более расплывчато.

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

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

Эмерджетность, в частности, обеспечивает стабильность систем и их сопротивляемость к серьезным изменениям. Так же как неэффективно воздействовать на атомы водорода и кислорода без учета их объединенности в молекулу воды, так же бесполезно проводить какие-либо существенные, но локальные изменения в компании без учета особенностей сложившейся корпоративной культуры.

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

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

[1] Любителей детективов предупреждаю, что множество деталей мною опущено, из-за чего сюжет может показаться нереалистичным. Но в самом рассказе выстроено все грамотно. — Прим. авт.

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

Я бы хотел сразу же добавить — речь пойдет о типичных ошибках типичных сисадминов/DBA и их менеджеров.

Традиционный подход к тюнингу (разросшийся как раковая опухоль «воооот такого размера!» с появлением хайповой темы облаков — которой болеют на моей памяти вот уже лет 12 как) — «Просто добавим ресов — у нас их мноооооого!» — порочный от начала и до конца.

Как правило, не просто не приводящий к желаемому результату, но усугубляющий проблему до предела.

На менеджерском и маркетологическом волапюке этот подход называется «capacity».

«Мы правильно рассчитаем capacity, мы просто увеличим capacity — и проблемы нет».

Никто не вникает и не желает вникать в такие тонкости, как архитектура процессоров, серверов, программного обеспечения.

Это неважно же. Просто навалим побольше capacity, а если этого недостаточно — в рамках тюнинга навалим еще больше capacity — благо, в облаках это нетрудно.

Вендоры (аппаратных и программных решений) этот подход поддерживают,
потому что он способствует продажам на шести- и семизначные суммы.

Я вас страшно разочарую. Это не тюнинг, господа.

Более того. Такой подход вылезет боком незамедлительно.

Типичная ошибка 1: «Просто добавим памяти!»

Рассмотрим кейс.

Ваш сервер содержит реляционную базу данных. Вы плохо оценили ее прирост, и, в какой-то момент, получили высокий IO. СХД захлебывается, CPU взлетел до потолка (вы понимаете, почему, да? У вас высокий wait IO).

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

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

 В чем проблема? В генах. Конкретно — в архитектуре, в которую никто не желает вникать.

Проблема в том, что реляционная БД имеет свой собственный кэш отложенной записи (иначе она физически не сможет быстро работать).

И этот кэш надо время от времени сбрасывать на диск. Этот процесс называется checkpointing.

(Открытие века — операционная система тоже со своими кэшами работает по такому же принципу. ОС обычно старается для скорости всю доступную ей память выделить под кэши. Да, она освобождает ее. По требованию процессов. Но перед этим ей тоже надо сделать — сюрприз! — чекпойнтинг. Нельзя просто затереть память дисковых кэшей и отдать их системному вызову malloc(). Результат немного предсказуем, не так ли?)

Что происходит, когда вы удваиваете память СУБД?

А все просто. Вам надо теперь сбрасывать в два раза больше памяти на диск.

Теперь многое становится понятным, не так ли?

Ситуация усугубляется, когда ваша СУБД работает не на bare metal, а в виртуальной машине. Облака же повсюду.

Как работают гипервизоры? А вот так: они по умолчанию до последнего не делают синхронизацию памяти гостя на диск. Сперва забивают всю доступную память, а потом, сильно потом, делают чекпойнт. Станет ли чекпойнт быстрее от того, что памяти, которую нужно синхронизировать, стало в два раза больше?

Очевидно, что нет.

Очевидно для кого? Вопрос риторический.

Правильное решение

А как нужно было? 

Парадоксально, но факт — память нужно не увеличивать, а уменьшать.

Вы скажете — «Стой, но у нас же база выросла! Уменьшим память — скорость вообще рухнет!»

А это, господа, требует несколько иного подхода. Нужно выяснять в деталях, а почему, собственно, скорость упала? Ага, потому что база выросла, а индексы ее экспоненциального роста не учитывали, некоторые не построены, а вот тут вообще запросы деградировали.

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

PS. В реальности ситуация усугубляется аллокацией памяти мелкими страницами по 4 Кб, что добавляет оверхед просто при работе с VLM (Very Large Memory). Не каждая система позволяет выделять память пулами (СУБД обычно позволяют, но ОС под ней — зачастую нет, либо не позволяет без специальных ухищрений). Это кажется мелочью, но оверхед на уровне ОС в подобных ситуациях достигает 15 и более процентов (не перцентилей, прошу обратить внимание).

Типичная ошибка 2: «Просто добавим корочек!»

Мы о CPU cores, если что.

Мой любимый случай. Есть консолидированная система. На сервере, имеющем два сокета с многоядерными процессорами. Архитектура сервера (уже много лет как) CMT. Система виртуализирована — гипервизор и всякое такое.

На сервере крутится СУБД. СУБД вырастает в размерах и начинает тормозить.

Вам пофигу, что происходит. Подход в лоб — Добавим СУБД корочек!»

Ведь верно? Добавим вычислительной  мощности — и проблема решена.

Вы удваиваете число ядер процессора, доступных СУБД, перезапускаете ее — опа! — скорость упала в три раза.

«Какого черта?» — думаете вы.

Вопрос номер один — а как устроены CMT-процессоры?

А устроены они так: один сокет, одна шина данных, которая совместно используется несколькими ядрами. При этом в каждый момент времени с шиной данных работает только одно ядро.

Да, внутри процессора есть кэши L1/L2 (и даже зачастую L3). Но они маленькие относительно оперативной памяти, и, в особенности, оперативной памяти СУБД.

(Проблема в локальности. CMT-процессоры эффективны в одном и только одном случае. Когда данные, обрабатываемые ядрами, высоколокальны. Что это означает? Это означает, что данные целиком помещаются в кэши процессора. СУБД — за исключением совсем крошечных — туда не помещаются и, следовательно, представляют собой низколокальные данные. Что означает, что они в принципе не могут работать на многоядерных процессорах эффективно, вне зависимости от числа доступных ядер, вне зависимости от скорости шины «процессор-память». Кроме того, чем больше ядер одновременно обращаются к внешней памяти, тем больше эти ядра ждут друг друга при доступе к аппаратной шине данных процессора. Она одна на всех, помните? Мы говорим о неймановской архитектуре.)

Если, в нашей ситуации, по несчастью, программное обеспечение lock-free — то есть нафаршировано атомарными операциями — то все становится много, много хуже (хотя lock contention в подобной ситуации не сильно лучше, но это отдельная тема).

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

Чем больше атомарных операций в коде — тем хуже все выглядит.

Если мы говорим о легаси-софте, который в принципе и не мог быть написан с высокой локальностью, или, еще хуже, был рассчитан на SMP-архитектуру — увеличение количества ядер не спасет гигантов мысли.

Скажу больше. Это только сисадминам кажется, что софт thread-unaware легко и непринуженно переписать в thread-aware. По факту, его придется написать заново. Представили себе переписывание Oracle с нуля в thread-aware? Вот то-то же.

Правильное решение

Нужно выяснять, что в точности привело к перегрузке процессора — узкое место в IO (не только дисковом), деградировавшие запросы, и так далее. Диагностика занимает в тюнинге центральное место, и, да — нужно в точности знать, куда ударить. И лишь потом надо устранять найденую проблему — но никак не добавлением корочек.

Типичная ошибка 3: «Мы сделаем кластер!»

Ваша реляционная СУБД стала тормозить. Даже после миграции на новый модный сервер. (Особенно после миграции на новый модный сервер). Выросла нагрузка на CPU, упала латентность, пользователи жалуются на резкое замедление ключевых запросов. Особенно в часы пиковой загрузки.

«Мы сделаем кластер с тремя нодами и разгрузим сервер!»

Одна из самых тупых и роковых ошибок администраторов и их менеджеров.

Приводящая к многократному возрастанию TCO, но не дающая абсолютно никакого эффекта в производительности.

Вы скажете — «Брешешь, косой! Почему тогда Пейсбук, Гугл, и все остальные используют кластеры повсеместно?»

Во-первых, вы не гугл. 😂😂😂

Во-вторых, кластеры — для горизонтального масштабирования вполне определенных структур данных и вполне определенных алгоритмов. Шардирование и так далее. И для весьма узкого круга задач (вычислительные кластеры и рендер-фермы это вообще о другом).

Мы говорим о реляционных СУБД.

Кластеры в реляционных СУБД разрабатывались для горизонтального масштабирования в ситуациях, когда нельзя было применить масштабирование вертикальное. В архитектуре SMP (это важно), которая принципиально отличается от современных CMT-процессоров.

(Лично я вообще считаю, что SMP значительно лучше CMT хотя бы потому, что все процессоры имеют собственную независимую шину данных, что, в случае многоканального доступа к памяти, избавляет нас от точки сериализации CMT в виде общей шины памяти всех ядер. Я вообще продолжаю считать, что CMT — это роковая ошибка в мире легаси-софта, который в принципе низколокальный. А переписать биллионы строк кода, дабы он эффективно работал на CMT — за пределами разумного. Почитайте доступные исходники ширпотребовского софта — вдумчиво почитайте. Здорово удивитесь, гарантирую.)

Администраторы ошибочно считают, что кластер — это о параллельной обработке (ошибка номер один), или что scalablilty =  performance. Более того, они считают, что кластер — всегда кластер, даже если он развертывается на односокетном CMT-сервере с кучей ядер, в виртуальных машинах, которые полностью эквивалентны машинам физическим.

В виртуализированных средах, на CMT-процессорах (даже с аппаратной виртуализацией) кластеры — это смерть производительности.

(Это помимо того, что, если софт лицензируется поядерно — то вы здорово попали на деньги с поядерным лицензированием плюс лицензирование clusterware)

Кластер на CMT попадает сразу в две засады. Первая — одна шина данных у всех ядер. Вторая — закон Амдала.

Я больше скажу. На CMT-серверах с виртуализацией применение кластеров — это почти преступление. Ну или, как минимум, адский непрофессионализм.

Правильное решение

Кластер должен быть кластером. То есть набором физически различных аппаратных серверов bare-metal (виртуализация добавляет ненужный оверхед). И кластер — это не о перфомансе, а о масштабировании. scalability != performance. Кластерами проблемы производительности не решают, если только речь не идет (повторюсь) о шардировании и экстенсивном масштабировании быстрорастущих систем.

В случае СУБД, кластеры (в вышеописанной конфигурации — раздельные bare-metal сервера) используются для High Availability, но никак не для High Performance.

В виртуализированных средах применение кластеров почти всегда не имеет никакого смысла, а лишь ведет к увеличению ненужного оверхеда, повышению TCO и к снижению производительности в целом.

Вернемся к нашим баранам — как же быть в нашем конкретном случае?

Способ 1 — если вы настаиваете на работе в кластере, то софт должен быть переписан для полного учета специфики работы в кластере (вендор лжет, когда говорит, что вы можете пересадить на кластер софт, изначально для этого не предназначенный. Эффективная работа софта в кластере требует специальных подходов, реализуемых на всех уровнях ПО.), что, разумеется, нереально.

Способ 2 — необходим алгоритмический (или, как минимум, низкоуровневый) тюнинг софта в критических местах для сохранения масштабирования. Возможно, с исправлением ошибок конфигурации и не только их.

Типичная ошибка 4: «Мы ускорим IO!»

Ваша СУБД выросла, нагрузка на CPU резко увеличилась. Вы справедливо решили (после диагностики), что в вашем случае имеет место wait IO, купили новую очень быструю СХД, с фабрикой, правильно ее настроили, мигрировали базу. И….. после миграции ситуация резко ухудшилась, а wait IO никуда не делся, более того, он вырос.

Одна из самых изощренных и трудных в обнаружении ошибок.

Что по факту произошло?

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

IO — это не только диски, это еще и network.

В вашем сервере четыре NIC, работающих независимо на четыре vlan.

Вы не догадались посмотреть на утилизацию интерфейсов, верно?

А по ним и бэкапы выполняются, и сервера приложений гоняют данные, и пользователи с прямым доступом к базе… не так ли?

Внимание, вопрос — вы, конечно же, слышали об агрегации NIC на L2?

Ах, вы считаете, что это не работает? Вам не нравится отсутствие честного round-robin? Вы действительно так считаете?

Правильное решение

Кроме необходимости оптимизации network IO на программном уровне (вас, возможно, удивит факт необходимости тюнинга сетевого стека, причем не только на уровне ОС, но и на уровне приложений), необходимо выполнить агрегацию линков для минимизации оверхеда и перегрузки отдельных NIC при независимой работе множества NIC, после того, как вы ускорили disk IO и стали подавать данные с дисков без задержек. Вне зависимости от предубеждений старшего сисадмина.

Отдельный кейс: вы приобрели новую мощную СХД с Infiniband и сотнями шпинделей. Однако, из каких-то своих соображений, вы отдали ее не единым массивом, состоящим из всех шпинделей, консодидированному серверу с десятками виртуальных машин и кластеров — а нарезали на LUNы из трех шпинделей каждый.

Ну а что, диски же быстрые, SAS и все такое, сверху присыпаны SSD — оно же в принципе должно летать, верно? (Многие вообще считают SSD этакой волшебной пулей, решающей все существующие проблемы одним махом. Правда, что ли? SSD имеют многоканальный доступ? Неограниченную скорость? В реальности SSD до поры-до времени маскируют имеющиеся проблемы. До поры. И — да, они имеют тенденцию внезапно умирать. А если не имеют — они стоят как крыло от Боинга 787)

Черта с два.

Throughput прямо завязан на количество шпинделей. Вы гигантский throughput нарубили на кусочки, каждый из которых состоит ровно из трех шпинделей и на корню ограничили пропускную способность по дисковому IO на каждую виртуальную машину.

Вместо того, чтобы отдать всю СХД виртуальным машинам как единое целое и разделить пространство доступом (директориями и пермишенами), вы раздробили ее на небольшие кусочки, каждый из которых имеет всего ничего шпинделей, но при этом число ядер CPU превышает это число шпинделей.

Что в итоге? Правильно, сериализация доступа и лимитирование скорости дискового IO тремя шпинделями. Кэширование в оперативной памяти и SSD здесь до определенных пределов нагрузки сглаживают ситуацию, но лишь до определенных пределов. Очень невысоких. При резком увеличении нагрузки возникает ситуация, описанная в первом случае, причем деградация производительности происходит экспоненциально.

Правильное решение

Ошибочные решения такого уровня обходятся чрезвычайно дорого. По факту, нужно реструктурировать СХД в исходное положение — все виртуальные массивчики сгрести в кучу, и перемигрировать данные назад. И, желательно это сделать за счет того, кто настоял на неправильной и абсолютно немасштабируемой архитектуре, в которую изначально заложен bottleneck. Запомните — такая работа не будет ни быстрой, ни дешевой. И будет связана с даунтаймами, снижением уровня сервиса, и так далее.

Заключение

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

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

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

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

Думайте, когда собираетесь что-то сделать — и вы сможете избежать большинства проблем до того, как они приобретут критический статус.

PS. Описанные выше случаи относятся не только к реляционным СУБД. Но и к остальным категориям софта.

Понравилась статья? Поделить с друзьями:
  • Тип ошибки 401
  • Тип логической ошибки алогизм
  • Тип звена регулятора при нулевой ошибке управления
  • Тип wan динамический ip неизвестная ошибка
  • Тип wan pppoe ошибка аутентификации